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…

https://blogs.oracle.com/ericv/entry/java_card_3_0_5

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:

Introduction

VCC Glitching example

Stay tuned!

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:

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 ;)

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…