суббота, 8 августа 2015 г.

New reliese of Java Card 3.0.5, Classic Edition from Oracle

One more proof of that security becomes so important. New release of Java Card 3.0.5, Classic Edition become available in June 2015. Let's have a look briefly what is new especially in security enforcement...


Package
Class/Interface
What is new?
javacard.framework

APDU
New constants to support JIS X 6319-4:2010 transport protocol Type F and Transport protocol Media - APDU over HCI defined for the APDU gate in ETSI TS 102 622 respectively.
OwnerPINBuilder
This class is factory for Owner PIN object
OwnerPINx
This interface represents an Owner PIN, extends Personal Identification Number functionality as defined in the PIN interface, and provides the ability to update the PIN, update the try limit and try counter and thus owner functionality.
OwnerPINxWithPredecrement
This interface extends the OwnerPINx interface, to support the decrementing of the tries counter before any PIN validation attempts.
SensitiveArrays
This class provides methods for creating and handling integrity-sensitive array objects.
Util
New methods arrayFill which fills an array in an atomic way and arrayEqual which compares two arrays.
javacard.security

DHKey
These interfaces support Diffie-Hellman modular exponentiation.
DHPrivateKey
DHPublicKey

KeyBuilder 
Additional support of Domain Data Conservation for Diffie-Hellman, Elliptic Curve and DSA keys.

Signature
  • oneShot method to support efficient one-shot, signing and verification
  • verifyPreComputedHash method to support verification of pre-computed hash.
  • New constants to support plain ECDSA and AES CMAC signature algorithm.


RandomData
  • OneShot()method to support efficient one-shot random number generation
  • getAlgorithm()
  • nextBytes()
  • New mode ALG_FAST, ALG_KEY_GENERATION, ALG_PRESEEDED_DRBG, ALG_TRNG

MessageDigest
Added new constants to support SHA3(224, 256, 384, 512)
javacardx.apdu.util

APDUUtil 
Contains utility functions to parse CLA byte from a command APDU.
javacardx.biometry1toN

Functionality for implementing a 1:N biometric framework .
javacardx.crypto

Cipher
  • Added new constants to support SHA3(224, 256, 384, 512)
  • OneShot()method to support efficient one-shot cryptographic operations.
  • New constant to support a cipher using AES in counter (CTR) mode.
  • New constants  to extend PKCS#1-OAEP scheme support to SHA224, SHA256, SHA384 and SHA512
AEADCipher
To support Authenticated Encryption with Associated Data (AEAD) ciphers. Only GCM and CCM modes of operation for AES are supported in this version. 
javacardx.security


Functionality, for implementing security countermeasures to protect security relevant applet assets on the Java Card platform.
SensitiveResult
Class which provides methods for asserting results of sensitive functions.
javacardx.framework.util

ArrayLogic
arrayFillGeneric and arrayFillGenericNonAtomic 
methods added

One more thing I forgot to mention is RSA 3K now supported.

Not so bad, right? Well let see than a first product will become avalible on a market…


Stay tuned!

Embedded Security - become a very important and hot topic today. How about you? Are you ready for a new challenges?

Today here and there people discussing importance of overall product security. More and more electronic devices become connected with each other through a public networks. IoT brings this new trend in our life. Apart of IoT there are plenty of other devices which supports connectivity but may have no access to public networks. All of them anyhow can be accessed by potential attackers who might want to still your private information or data which might be sensitive to you. Moreover they could change behaviour of your device in such way that at least bring you a lot of problems and even might be dangerous for your life (health care devices for example).

There two aspects of embedded security: SW and HW. What is important to understand, is that they are both could not be developed without taking into account specificities of each other. Otherwise overall security will become Inefficient. To better understand influence of SW security and possible weakness in its implementation designer and developer must closely work with HW developer and be able to analyse HW behaviour when it is driven by his SW. Usually this kind of equipment cost a lot (thousands kilo $) and only big companies can have it at their RnD department. But things are changing and people start to think about that more and more. One of a good example I found recently on www.kickstarter.com is ChipWhisperer.

ChipWhisperer and target board



"The objective of ChipWhisperer is nothing short of revolutionizing the entire embedded security industry. Every designer who uses encryption in their design should be able to perform a side-channel attack, and understand the ramifications of these attacks on their designs."

Here are some videos about subj:

четверг, 22 мая 2014 г.

Unpredictable number is not always Unpredictable. A new attack on Chip and PIN cards.

Serious security flaw has been again identified and then presented on 19th of May at the 2014 IEEE Symposium on Security and Privacy in San Jose, California by group of researchers from Computer Science Department in Cambridge University. The Group includes Mike Bond, Omar Choudary, Steven J. Murdoch, Sergei Skorobogatov and Ross Anderson.

Chip and Skim: cloning EMV cards with the pre-play attack

Actually the issue with Unpredictable Number has been already presented in 2012, but this time they improve the attack by identifying a second flaw. By the way this is not a first time when same security group reported about security flaw in EMV standard. The first issue has been raised in 2010. They said: Chip and PIN is broken. Indeed, when you put a card into a terminal, a negotiation takes place about how the cardholder should be authenticated: using a PIN, using a signature or not at all. So they trick the card into thinking it’s doing a chip-and-signature transaction while the terminal thinks it’s chip-and-PIN. The upshot is that you can buy stuff using a stolen card and a PIN of 0000 (or anything you want).

So it means we are living in not perfect world, and when it comes to security, we have to keep in mind, cybercriminals are not sleeping and they are just behind you...

And just to give you an idea how it could be done in a real life, please watch a BBC video below:



пятница, 26 июля 2013 г.

ST32F4DISCOVERY - New project is ongoing...

Very powerful board, I guess I know what to do with this staff. So IO is work fine, LEDs are blinking, ADC seems ok, so and at the end of the day USB lib was compiled, and Virtual Serial port working now fine. So good start, let's see what will be the next actions ;)

четверг, 30 мая 2013 г.

Terminal - Banking Chip Card. How they are talk to each other?


Introduction.

Today was a hard day for me, even if it was Sunday...but anyway I want to start a new very interesting topic about one standard, which is actually playing very important role in a world of Payment application, its name is EMV.

Everyone today has his own banking card, and this is easy way to get the access to your bank account and as a consequence to your money. Whatever you do, going to buy something, to get some cash or to pay for your mobile phone, each time you take your card from your wallet and starting from this moment you oblige to follow some rules in order make a correct payment. To be precisely, it is not you personally, this is your banking card which should be complained to EMVco standard. Let's imagine you insert your card to the reader of ATM or POS terminal and from this moment magic is takes a control on your bank account. Interesting, is not it? Let's see what is going on between your card and ATM or terminal.

First of all, I will give you some useful links about related topics, which I hope will help you to understand the process of data exchange between smart card and terminal and also helps to read this topic.

       ISO 7816 general description.

       Global Platform general description and full set of documents which can be downloaded from official web site.

       EMV on wiki and EMVco website where you can find all specifications.

       Nice page with EMV tags search engine

       ASCII to HEX/HEX to ASCII convertor

Let’s start to see what is going on between card and terminal. I need to say here, first we will speak about contact interface.About contactless interface I will describe later on.

Part I. EMV transaction via Contact Interface.

When the card inserted in to terminal, it is going to be powered and reset. Card must provide Acknowledge-To-Reset (ATR) and then will wait for incoming commands.
This is a common part which is not directly related to EMV transaction. More information about ATR you will find in ISO7816 part 3. So, now let’s have a look from EMV standard point of view.

The next step is to choose and select target application. Depending on what type of card you have (Visa, MasterCard, etc...), different payment schemes will apply during EMV transaction. 

There are two approaches can be used to determine which application is going to be used:

1.      Terminal use PSE (Payment System Environment), if the one is exists on card.
2.      Terminal build a list of candidates based on list of application stored in terminal.

Approach 1:  Using PSE

PSE is Payment System Environment which contains, roughly speaking language preference, list of applications and their priority in which they must be executed. It is not mandatory for all cards to support PSE.
Terminal select PSE using SELECT command with filename 1PAY.SYS.DDF01. If there is no PSE, card should return “6A82”, which means “file not found”. If card returns “9000”, terminal proceeds to the next step by processing response from card. The response on the SELECT command for PSE contains FCI data object, which should looks according EMV Book 1 like:

Tag
Value
Presence
6F
FCI Template
M
 
84
DF Name
M
A5
FCI Proprietary Template
M
 
88
SFI of the Directory Elementary File
M
5F2D
Language Preference
O
9F11
Issuer Code Table Index
O
BF0C
FCI Issuer Discretionary Data
O
 
XXXX -Tag according EMV Book3, Annex B
1 or more additional proprietary data elements from an application provider, issuer, or IC card supplier, or EMV-defined tags that are specifically allocated to 'BF0C'
O

Response on SELECT command for PSE

 So now terminal knows the SFI of payment system directory to read. By sending READ RECORD command with record number beginning with #1, terminal is able to read data and continuing with successive records until the card returns “6A83”, which means record number requested does not exist. Here terminal should stop reading.
Payment system directory is represented by linear EF file identified by SFI. A record may have several directory entries; basically the format of the record according to EMV Book1 is looks:

Tag
'70'
Data Length
(L)
Tag
'61'
Length
of
directory
entry 1
Directory
entry 1
(ADF)
Tag
'61'
Length
of
directory
entry n
Directory
entry n
(ADF)

Payment System Directory Record Format

Terminal process all directory entries and match ADF names with his own list of supported applications. If ADF name is equal to one supported by terminal, it join then the list of candidates for final application selection. When the terminal finishes processing all records, if at least one matching ADF name was found, the terminal makes the final decision in according with EMV standard. The process to take decision which application is going to be selected and used is conditional. You will find complete description in EMV Book 1, section 12.4 Final Selection.

For example, let’s have a look to the trace below:


T: RESET
C: ATR

T: SELECT
00A404000E315041592E5359532E444446303100

C: RESPONSE
6F20840E315041592E5359532E4444463031A50E88010A9F1101015F2D046672656E9000

T: READ RECORD
00B2015400

C: RESPONSE
701761154F07A0000000421010500243429F120243428701019000

T: READ RECORD
00B2025400

C: RESPONSE
702761254F07A0000000041010500A4D4153544552434152449F120A4D4153544552434152448701029000

T: READ RECORD
00B2035400

C: RESPONSE
6A83

As a file name, SELECT APDU contains the name of the PSE, which is in our case 1PAY.SYS.DDF01 or in a hex format “315041592E5359532E4444463031”. In the response of SELECT we can see the tag “6F” which gives us FCI content.  Tag “84” contain name of PSE. Tag “88” gives us the SFI=0Ah. Under tag “5F2D” we can see the preferred language which is in my case “6672656E”or ASCII representation is “fren”, which means French language, cause my card is French one.

Now Terminal knows the SFI of file which contains directory entries and can easy read it by using READ RECORD cmd. From the trace above, we can see how it looks.

By parsing the READ RECORD command response, we can easily identify following parameters:

Tag
Meaning
Hex Value
Description
4F
AID
A0000000041010
Application ID
50
Application Label
 
4342
4D415354455243415244 
CB
MASTERCARD
9F12
Application Preferred Name
 
4342
4D415354455243415244 
CB
MASTERCARD
87
Application Priority Indicator
01
02
CB
MASTERCARD

Here CB (Cartes Bancaires, French) is “CB Bank card Group”, short description you can find in wiki.

Approach 2:  Using a List of AIDs

If at any reasons, terminal was not succeed with PSE to identify the target application, or PSE is not supported by the card, terminal will need to build the first the list of candidates by selecting one by one the applications, base on application’s list stored in terminal.

In this case, terminal send in the loop SELECT command and tries to match the AID with DF Name field returned in the FCI on SELECT command. If they are matches both together, the AID is going to be add into the list of candidates. So, again after the list is ready, terminal is going to take the final decision like described in EMV Book 1, section 12.4 Final Selection.

So, the next step is to select the target application. To do that, terminal sends the SELECT command with ADF name chosen in previous step. We will see how it works in my next topic. Well, that is enough for today, I think…