JavaCard OS

Symmetric algorithm use the same session key to encrypte and decrypte data. The session key is generated dynamically and uniquely for each time transaction. So, What exactly is session key ? pls help me regarding this.

You don't need to use Session Key. It can be a static key or a dynamic session key. It doesn't really matter as long as it is the same on both sides.

Can I create session key in the Java Card 2.2.2?

Of course you can. Keep in mind that crypto key is just a string.

Are you trying to use the SCP02/03 and trying to find their session keys ? What kind of session keys are you trying to find ? You need to put more detail into your question as it's too abstract for us to know how to reply your question.

tay00000 wrote:Are you trying to use the SCP02/03 and trying to find their session keys ? What kind of session keys are you trying to find ? You need to put more detail into your question as it's too abstract for us to know how to reply your question.

Sorry, I was just getting started with implementing Encryption and Signature in the java card. So this question is only for me to know some basic content about sesson key. and how to create session key. I haven't implemented it yet.

If you want to hack card and terminal communication, i advise you to give up.
If you want to implement the session mechanism, you can refer to GlobalPlatform specification and source of opensource project GPShell or GlobalPlatformPro.

There are two options to approach card session encryption.

1.) SCP 02/03 as per GlobalPlatform specifications. Note that SCP encryption only encrypts the APDU Command data (without the headers - CLA, INS, P1, P2, LC) sent from the host computer to the card while the response is not encrypted. MAC-ing of command and response can be applied both ways though and includes MAC-ing of the headers.

2.) Implement your own session encryption (which I personally prefer more). This gives much more fine grain control and allows two way (response/request) security and besides that, the protocol I use for projects I create also hides the actual INS, P1, P2, LC into the data body (encrypted) while leaving a generic header outside and also fully pad the entire traffic (both request and response) so that an attacker somehow capable of observer on the wire (listening to traffic between reader and card via a shim or other MiTM techniques) will not know the true length of the traffic and true intentions (via encrypted headers).

It is good that you ask about the session security as many of the payment card attacks these days are not directly attacking the Secure Element but are mostly card skimming and shimming, pin capturing, hidden cameras and the sorts. One of the most commonly reported attacks by financial institutions are card shimming (using the device above - cheap and easy to create) to do a MiTM on the information traffic between a reader and card session that does not have encryption.

Overlay SIM cards and "hobby cards" can be purchased off the shelf or even on Ebay that one can program and modify to be used as basis to create the shim tool shown in the picture above.

As card developers for security critical applications, we have to take utmost care on how we develop secure card applications and should not be careless as the impact not only looks bad on the industry but also have significant impact on the consumers, merchants, institutions and many more.

If you are interested on implementing a custom two-way cryptographically secured protocol without relying on GP-SCP standards (GP SCP doesn't take care of traffic analysis and response encryption which seems like a rather sloppy job), I can give you a helping hand here and also at the same time open source the protocol for anyone interested to use as a means to step up their smart card security.

Here's how a ATM card shim looks like:

Here's my method of designing a Secure Channel Protocol customized for your own application.

THE A02 SCP PROTOCOL
====================

Assumptions:
- APDU buffer at least 256 bytes
- RSA-2048-PKCS1-1_5 Cipher is available
- AES-256 in ECB and CBC mode is available

Tested & Proven Hardware:
- Feitian A22CR
- NXP J3E081 (Feitian's ePass FIDO not sold here)
- Feitian C21C (not sold here and not available anymore - legacy card)

Abstract:
- Card generates it's own public key, executes key exchange with host computer and calculates a symmetric session keyset (Encryption and MAC session keys) and a message counter.

Benefits:
- Asymmetrically protected protocol (similar to SSL/TLS concept) with familiar setup.
- Using a unique 4 byte message counter to prevent message replay attacks.
- Protects INS, P1, P2, LC by wrapping them into encrypted payload and only exposing a generic INS, P1, P2, LC value to fool attackers trying to perform traffic analysis of secure traffic.
- Fixed length message making the encrypted and MAC-ed message all having the same message length thus also contributing to traffic security.

Cons:
- Very heavy and bulky with high cost of setup and processing.
- Messages may need to be split into many portions to send to card and also to get proper respond.

Protocol Description:
- Hardware / Card generates a permanent SCP key (RSA 2048) -> KeySCPCard.
- Host generates a one-time RSA 2048 keypair -> KeySCPHost.
- Using a secure host / air-gapped computer running hardened OS, extract the KeySCPCardPublic public key from the card.
- Host generates a 24 byte nonce -> NonceHost.
- Host encrypts NonceHost with KeySCPCardPublic and sends to card while also sending it's public key -> KeySCPHostPublic.
- Card decrypts NonceHost with it's private key -> KeySCPCardPrivate.
- Card generates 28 byte nonce -> NonceCard and sends to Host while encrypting it under KeySCPHostPublic.
- NonceCard is make up of 24 byte cryptographic nonce and 4 byte is the session counter.
- Host uses KeySCPHostPrivate private key to decrypt the 28 byte nonce sent from the Card.
- The first 16 bytes of NonceHost and first 16 bytes of NonceCard are combined into a 256 bit AES session key.
- The last 8 bytes of NonceHost and last 8 bytes of NonceCard are combined into a 128-bit HMAC-SHA256 key.
- An authenticated and encrypted message is sent with the genuine counter as follows:
* Actual CLA
* Generic INS
* Generic P1
* Generic P2
* LC = 0xFF (256 bytes)
* 16 byte IV
* Encrypted Payload (208 bytes)
> Actual INS
> Actual P1
> Actual P2
> 4 byte session counter
> Actual LC that are plaintext and not zero pads
> Payload (200 bytes and must be zero padded if the payload does not fill 200 bytes)
* 32 bytes HMAC-SHA256 of IV and Encrypted Payload
- If session counter is incorrect, it would result in an error in the messages following and to prevent bruteforcing for the session counter, a limit can be set to ensure that once a certain amount of consecutive incorrect session counters are encountered, it would destroy the session and session keys and counter and force a reset to the session.

/up.