Differents between SDA and DDA in JavaCard?

0
votes

I have an applet (you can take a look at it there JavaCard applet is not working with RSA encryption). Applet generates RSA public and private keys in constructor and with APDU command encrypt some byte array.

Applet generates public and private keys with KeyBuilder.LENGTH_RSA_2048 in docs provided with cards sad that JavaCard supports 2048 bits key length only in DDA.

So question is what is DDA and SDA. Differences between them? And main question is: how to install (or run?) applet in this mode?

What I found out: Update 1: SDA -- Static Data Authentication DDA -- Dynamic Data Authentication

2
javaencryptionappletrsajavacard
"...in docs sad that JavaCard supports 2048 bits key length only in DDA. " Uh, that's not clear to me. I know new cards that go much higher than that. Where is such a limitation specified? – Maarten Bodewes
Oh, I must specify that docs exactly for cards I have. – raiym
EMV specs generally set the maximum key length to 1984 bits. This is mainly due to the requirement to fit within 256 byte response limit of the card and be able to wrap that in TLV (that's where additional 8 bytes are lost). Similarly, only maximum of 127 bytes of issuer scripts are guaranteed to be forwarded through interchanges, therefore the maximum length of APDU command is 123 bytes. Of course that limit may not apply to on-us networks and direct connections. – Michal Gluchowski

2 Answers

2
votes

So question is:

what is DDA and SDA. Differences between them?

SDA - SDA ensures the authenticity of ICC data. After SDA it is sure that the data from the ICC is real and hasn't changed by anyone. But SDA doesn't assure the uniqueness of ICC data. You can see the diagram of SDA is like,

SDA FLOW:

Here you can see two RSA Pair is using during SDA,
(1) - IssuerRSA

(2) - CA_RSA

this diagram is very descriptive and clear to understand the flow of SDA. Also you can check EMV BOOK 2 for more description about SDA. while DDA flow is like ,

DDA FLOW

here you can see 3 RSA Pair is using in DDA,

1 - IssuerRSA

2- CA_RSA

3 - ICC RSA ( new RSA key which is unique in all card, Each card generate this RSA pair during personalization of card so this RSA Pair will be different for each card)

SDA guarantees that data on cards is valid because we trust a high level certification authority which signs the data. But an attacker can record a card session and build for example a new virtuel card because same data is used here for all session.

But in DDA flow - we can say it is checking SDA + giving random data to card by Terminal to sign and here this part makes cloning of card impossible because each session use different random number so recording a card session will not work in next card session.

hope it helps and more can you read from SDA and DDA , Gemalto

1
votes

DDA implies Cipher.ALG_RSA_NOPAD algorithm (which is sometimes referred to as raw RSA or CKM_RSA_X_509) -- as @Hai-Binh LE noted, have a look into the EMV Book 2 (probably Annex B2).

You are instantiating a Cipher.ALG_RSA_PKCS1 which is not used for DDA, thus might be unsupported by the card.

You could verify this by inspecting the thrown CryptoException for CryptoException.NO_SUCH_ALGORITHM reason code.