Need advice on cryptographic algorithm

Question

Apologies for the essay-like nature of this question. I have been struggling to get to grips with this and have tried to sum up my understanding of what is needed, with the specific questions I have.

In this question relating to reading data from a European DTCO company card, I was given advice that involved following the algorithm in the screenshot below (from Appendix 11 of this document) but I'm not clear how to perform the two highlighted steps.

1. I see that Sign is a segment of the array containing the certificate but what does it mean to open it with the public key? I can successfully perform the step before by reading CA_Certificate from the card and issuing a MANAGE SECURITY ENVIRONMENT APDU using CAR´ (see first step of algorithm) from it. But having selected the public key that way, what public key do I use in the open Sign step. The MSE selects one but I don't have it; I have only the European public key from ERCA, but is that the same key I have selected in the card? I don't have any private keys, but would I need them.

2. In the step for checking that Hash(C´) = H´, how should I calculate the hash? There seem to be so many different ways (is formats the right word?) of doing encryption/decryption/hashing that I'm quite confused.

All I really need to be able to do to read the data I need is to authenticate using EXTERNAL AUTHENTICATE, immediately after a GET CHALLENGE that returns an 8 byte challenge. I presume I need to use that to calculate the cipher for the EXTERNAL AUTHENTICATE. I found the sample code below (see full post) and although it appears to be in some C-like scripting language (I'm using C#) and for a different type of smartcard it seems quite similar to what I must use.

//
// Authenticate against CardOS card
//

var card = new Card(_scsh3.reader);
var crypto = new Crypto();

var key = new Key();
key.setComponent(Key.DES,
    new ByteString("01010101010101010101010101010101", HEX));

// Get challenge
var challenge = card.sendApdu(0x00, 0x84, 0x00, 0x00, 8, [0x9000]);

// Crypto.DES_MAC_EMV is a CBC generated Retail-MAC
var cipher = crypto.sign(key, Crypto.DES_MAC_EMV, challenge);

card.sendApdu(0x00, 0x82, 0x00, 0x81, cipher);

print("Card returns " + card.SW.toString(16) + " - " + card.SWMSG);

Differences are

1. The additional P2 parameter indicating that MANAGE SECURITY ENVIRONMENT has been done, presumably with the CAR´ from Card_Certificate, which doesn't work for me, though it does with the CAR´ from CA_Certificate.

2. Lc of 0x80 instead of the 0x81 in the sample code.

3. Any cipher I calculate to use here would have to be 128 bytes long while it's unclear of the cipher length in the sample.

Answer 1

Don't do this your self, a lot of things can go wrong. The bouncy castle crypto library does support ISO 9706-2 signatures. It works in both c# and java.

The very beginning of this paper makes it clear whats going on. Originally what you get back from the card is

x_c = sign || c_n || c_ar 

Sign is an RSA signature on the output of an encoding/padding/hash function on your message ( in this case it appears the message is a certificate). c_n is the rest of the message and c_ar is the identifier of the certificate authority who created the signature sign.

The encoding function used is µ(m) = 6A || m[1] || hash(m) ||BC

where || is concatenation, 6A is just the bytes 0x6A, likewise for 0xBC. Hash is some hash function, and m1 is the first k - length of hash function - 16 bits of the message. m[2] then is the rest of the message and whats stored as c_n.

DES is not involed here.

What you are supposed to do here is

1. Get the message/certificate by concatenating \m1 and c_n
2. compute µ(m[1] || c_n)
3. Verify that sign is the rsa signature on µ(m[1] || c_n) by the certificate authority indicated in c_ar

Answer 2

This answer is also a bit lengthy, because a misunderstanding has to be explained. The text excerpt above deals with authentication by an asymmetric key pair. Since one can prove nothing beyond possessing the private counterpiece to a public key, additional credentials are required. The issuer of the certificate typically claims to have verified your identity and this is documented by the certificate's signature (The signature is only useful if the issuer's public key is well known from the internet or because it is stored on the card already). Typically a smart card provides the command "Perform Security Operation" in the mode "Verify Certificate" for such a purpose: it verifies the issuer's signature, unpacks the public key contained in the certificate or delivered together with it and preserves it for inverting a private key operation assumed to follow soon.

Your code snippet deals with authentication by a symmetric key, also called secret key. It is assumed that this secret is only known by authorized people. The 0x81 you consider as LC is actually P2, meaning "please take the local key #1" for verification of the MAC computation using this secret key. In fact taking an 8 byte random number as input for computing a (retail- or whatever) MAC will typically (i. e. applying standard padding-schemes) result in a 16-Byte result. By the way, the DES key in the example is horrible. The least significant bit of each byte is the parity bit, so the key consists of zero bytes only.

Both schemes have nothing in common beyond the purpose of somehow doing an authentication.

For further information see ISO 7816-8 (for Perform Security Operation), ISO 7816-4 (for External Authenticate, Get Challenge, and most other of smart card commands). These are hard to get without spending money - older versions may be found on the www - and quite dry to read and difficult to understand. More explanation is found in Rankl/Effing "Handbuch der Chipkarten", but the English translation "Smart Card Handbook" is reported to be special sometimes. For certificate stuff I'd recommend Schneier, Applied Cryptography, which also has hundreds of further references.