SCP02
I write this blog to re-enforce the little of what I understand. Most of the sentences here are spontaneous, with minor later editing. Making this blog private de-motivates me to make it correct
Sat, Jun 13, 2020 7:42:39 AM
This is about the GlobalPlatform Secure Channel Protocol 02 (SCP02) technicalities.
So that the bytes that goes into the card is not readable by anyone that sniffs on the transmission medium, the two communicating entities shall use a secure channel protocol. These two communicating entities we shall named as:
offcard (or the laptop)
card (or the Java Card applet inside the smartcard)
The communication medium is either wired (via USB) or wireless (via NFC). The Global Platform specification defines the requirement of the SCP02. The smartcard uses the Java runtime environment or JCRE as its operating system interface layer on top of which an application shall run, known as an applet. The Global Platform also defines the presence inside the smartcard some core security applets whose responsibility is to register and manage the user applets. Therefore, user applets shall be installed into the smartcard using the mechanics defined by Global Platform. You cannot go inside the house through the backdoor.
Unlike in the desktop JVM world where an instance of java hello runs on its own JVM and various classes inside can easily communicate to each other. There is only one JVM running inside the smartcard! But this is a modified JVM so other applets are firewalled from each other. The smartcard is designed to accommodate several applets from multiple organizations just like we have firefox and chrome browsers. We have mspaint and MSWord too. Therefore, many cooperating or competing applets can co-exists and execute inside one smartcard.
The Global Platform defines the SCP02 in a PDF document it describes the necessary cryptographic primitives to be used and other operational sequence so that the offcard and the card can prove each other's identities and establish a secure channel for secure communication. An identity has component keys ENC, MAC and DEK. A proof means possessing same value of a key. Proof is not instantaneously bidirectional.
The SCP02 uses symmetric cryptography. This means that both the card and the offcard are already setup to have the same keys, a priori. On how the keys got there, is not part of the protocol. The keys are just there to begin with.
The communication of the offcard and the card relationship is one-sided. It is always the offcard that opens the communication and the card shall only reply. In order for both the card and the offcard to truly ascertain that they are communicating to a legitimate entity (not an impostor), the SCP02 protocol is used. Take note that this identity doubt is on both sides. The offcard or laptop cannot be sure who is inside the card because card may look the same, but what about the running applets inside it? The card also cannot be sure who is at the outside world that is sending data to it. Both of them possessed the same key sets (symmetric keys), but neither of them can send this key to prove who they are, because of the below common sense reasons:
If the offcard securely sends its key to an impostor card, then the impostor card will know the key and will pretend to impersonate.
If the offcard sends its key to a real card, then somebody is sniffing on the communication and can read this key.
There is just no easy way to introduce each other by giving out an ID like how humans would do to introduce who they are. In the following narrative we shall see how these two entities can be introduced to each other without giving out their keys. I am in awe of this mechanism, as it felt the same when playing chess through the moves alone you can know who is at other side of the board. Identification by computation. This was how Seraph identified Neo in the movie The Matrix
The SCP02 defines the steps that needs to be done so that the offcard and the card can prove each others identities. For digital systems without eyes and ears, this is not an easing thing to do. In addition to proving each others identities, the communication channel is also secured. Cryptography is a method to make something unrecognizable. And then, this very same method becomes the means to certainly recognize something. Let us begin:
I. Card Proves to OffCard
Take note of the irony in the Card Proves to OffCard title. The card cannot initiate the communication to the offcard because the card can only reply. It is the OffCard that initiates the very first communication. But it is the card that first proves its identity.
The offcard sends 8 random bytes and a key_indexto the card. I call this the host_challenge
The offcard decides to sendkey_index 00 . The 8 bytes are randomly generated 56372B20A7F122BC
Starting here is a key concept not many knew or they take for granted. A key_index of 00 means the offcard lets the card choose which key set to use. The 80 50 is what is called INITIALIZE_UPDATE in the CLA, INS byte specification.
The card receives this. The card now parse the components of this first message:
4 bytes command
80 50 00 001 byte length
8 bytes
host_challenge
It is now time for the card to parse this received message. First let us describe this particular very special 2 bytes in the card.
The card, as in the spec, maintains an incrementing two bytes counter called sequence counter. The card generates only 6 random bytes. The 2 bytes from the sequence counter is concatinated to the 6 random bytes to form the card_challenge = AAA0 5905AAB0DD27
The sequence counter here is AA A0 and is concatinated with 6 other random bytes to form the 8 bytes card_challenge array.
Because key_index is 00, the card then looks up into its list of keys and the card decides and chooses an index of its own preference. It is expected, that the offcard also possessed the same key set pointed by an index in order to continue SCP02. Otherwise, there will be a cryptogram mismatch if key sets under a given index do not match. Or if the index is missing, there will be the No such key error.
The selected 16 bytes keys (selected via an index) together with the sequence counter and using DES cryptography with IV of 0's SHALL produces three session keys of 16 bytes each. They are usually named as:
sessionKey_ENC (16 bytes)
sessionKey_MAC (16 bytes)
sessionKey_DEK (16 bytes)
Think of these newly generated session keys as ephemeral doppelganger versions of the true ENC, MAC and DEK keys which is always kept secret never goes out. NEVER.
Which among the keys of ENC, MAC or DEK to use is also describe in the SCP02 protocol. It is expected that the offcard shoud be able to arrive at the same values for ENC, MAC and DEK. The knot that assures this equivalence between card and offcard are the following:
sequence counter
key index
a common key listing
The sequence counter is publicly readable. The key_index can be sniffed during INITIALIZED_UPDATE. The key listing, however, is never revealed for it holds the keys to the kingdom. It is not revealed even among its inner circle, but is instead computationally verified in the inner circle. Just like how Seraph verified Neo in The Matrix
Cryptography has this magical property wherein you can prove that a equals b without retrieving the actual values of a and b . Again, there is something similar in chess with regards to this property. It has to do with proof-of-work.
The card concatinates the host_challenge and the card_challenge arrays to form a 16 byte array we shall name as hostcard_challenge. The card calculates the cryptogram of hostcard_challenge using sessionKey_ENC . Therefore, the card uses the ENC key to introduce itself to the offcard. You shall later see below how the offcard introduces itself to the card, which varying granularity dependeng on wither the offcard encrypts the message or just tagged it. Let's cut to the chase: down later explained below, if the offcard's second packet is encrypted then the offcard is introducing itself to the card via possession of ENC and MAC key.
Below the arrow going right is what offcard sends to card, and the arrow going left is the card's response.
It is now time for the offcard to parse the card's response.
Ignore the first 10 bytes in the card's response, it is known as diversification data. The 03 is the index choosen by the card. I marked with ?? where the offcard pass 00 to emphasize the fact that the offcard lets the card to decide on the index. The 02 means the card uses SCP02 protocol. It is elegant how the offcard is not assuming or forcing with regards to the protocol, and the card being the low-powered it decides what its protocol is. Using the 03 ,the offcard indexes into its own list of key sets and do the same thing what the card had done to come up with hopefully same values of ENC, MAC and DEK. The offcard constructs the hostcard_challenge by concatination of the host_challenge and the card_challenge that it receive now from the card (those marked as dots above snippet is the card_challenge). And then the offcard computes the cryptogram of hostcard_challenge and compares result against what the card computed which is in the response those marked as asterisk in the above snippet. If the 8 bytes cryptogram matches, then the offcard can conclude that the card and the offcard has matching ENC key. Take note, at this stage the card still has no proof of the legitimacy of the outsider (ie offcard) that is trying to send data to it. The INITIALIZE_UPDATE only proves the card's ENC key value to the offcard. Also take note, that the actual value of the core symmetric keys did not travel in the wire (or air) in this proving business. Even the session keys did not travel over the wire as well, but instead they are computed. The relevant pieces of information that travelled over the wire were the following.
The notation o -> c is a shorthand for offcard -> card and vice versa.
INITIALIZE_UPDATE what travelled across the wire unencrypted:
Information
Description
Direction
host_challenge
It is an 8 bytes random array that the offcard generated and becomes a content of the very first message that the offcard sends to the card
o -> c
key_index
The index value that the offcard decides to use. If this value is 00, then the offcard lets the card to decide which index to use
o -> c
card_challenge
The first 2 bytes is the card's sequence counter and the 6 bytes is randomly generated by the card. The sequence counter increments for every successful SCP02 establishment. So this is a measure of how many offcards the card has talked to securely.
c -> o
key_index2
The index that the card uses for the key set.
c -> o
card_cryptogram
An 8 bytes computation result on the hostcard_challenge data using the session key generated from the index
c -> o
I'm not including in the list the diversification data 10 bytes those bytes are not included in the particular secure channel setup here. I am sure those bytes are important addition to even increase the security, but i only discuss here the core fundamental parts.
Both the offcard and the card keep a listing of key sets in such a way that an integer index points to the same key on both. The offcard or card may have more items in its own copy of the key listing, but the important thing is that whatever index gets used, it must point to the same key set. Take note also, this first stage of contact of the card and the offcard is not in a secure channel so we expect that a sniffer has knowledge of the information listed in INITIALIZE_UPDATE unencrypted what travelled info table above.
I forgot to mention late now, but the key listing you can visualize as something like:
ENC
MAC
DEC
63e88d8dd77a7f61afa37d73211c43ab
82a3384eeed80b0627f3e3074596dc96
0d2e02a8e7187cb1be97185a7781af2e
68c519fd95926e66c9df4e86ba826ee6
ed0567693a84538836e0244ebb819831
5ea71cc85ccf2f0b6c4a99cbb1641b85
e4b8c16d0a660f9e12c17c9ae25cfd2e
881871e60411425cc0f62141b0bc9411
8c19c2b174baaf3635dd882a849664e8
The key_index picks a row from this key set table. Each row has 3 columns for ENC, MAC and DEK which are nothing more but just cryptographic keys with specific purpose following the SCP02 protocol. I also forgot to mention there is a special key_index whose value is FF to mean that, both the offcard and the card shall use the factory default key setting which is 40..4F well known value for each of ENC, MAC and DEK. I think this factory default specific value is decided by a manufacturer such as NXP Semiconductors and not by the Global Platform spec. Whatever is the value of the default key set, the vendor must tell you about it. Otherwise, you cannot use your newly bought Java Card. But here is wisdom: Once you add your personal key set, the factory default key index signified by FF is vanished forever and your newly added key set shall become the keys to the kingdom with that specified key_index value.
II. OffCard Proves to Card
Secure channel is not yet setup. The offcard now decides the texture of the secure channel (of the card's protocol). By setting these bit fields:
MAC tag every message sent to card (
00000001)Encrypt every message sent to card (
00000010)MAC tag card's response (RMAC) (
00010000)Encrypt card's response (RENC) (
00100000)
Contrary to what one expects, a secure channel is not necessarily encrypted. The minimum is that a message has a MAC tag attached to it in order to prove that the message is not modified and it is coming from the legitimate sender. But as written in the SCP02 specification, if the message is encrypted then a mandatory MAC must be attached. Take note, that in theory of cryptography the attaching of MAC in an encrypted message is not a core requirement. You can encrypt without involving MAC. But in the SCP02 protocol, it is written to do it this way. I'm saying this to have a distinction between cryptography concepts versus a security protocol implementation.
Up until at this point, let us described what just happened. First the offcard sends its first packet to the card. Next, the card responded and the offcard received this response. No secure channel is setup yet.
Now, the offcard is about to send a second packet.
Let us take the case where the offcard decides to established an encrypted secure channel. The offcard must set two bits corresponding to MAC(1) and ENC(2) bitfields. Or in binary, 00000011 .
The variable that carries this piece of info is the securityLevel.
The offcard concatinates the card_challenge and the host_challenge arrays together to form the cardhost_hallenge 16 bytes array. The offcard computes the cryptogram of cardhost_challenge array using DES and sessionENC key with ICV of 0s. By the way, the hairy details please read in code, but the important thing here is the high level of what is happening. You will notice, that these are the same steps that the card did to the hostcard_challenge array. This time, the offcard is doing it to the cardhost_challenge array. The two arrays are in reverse concatination stare very closely don't blink. However, at this phase is the beginning of deep cryptographic voodoo which is why I am drafting this blog so that I can understand it. You can stare forever a 10 line simple cryptographic application code and never understand it if you don't take the time to understand cryptography. This is not javascript where you type very fast very loud, and then take a sip of coffee feeling like master of the universe.
I will skip the minute details, but I will emphasize the semantic portions and procedures that makes sense. The offcard is now about to send a second packet to the card. This second message is still not encrypted. The first message (during INITIALIZE_UPDATE) only proves the card ENC key. The second message (termed as EXTERNAL_AUTHENTICATE) shall prove the offcard's ENC key to the card. In addition, it also carries the offcard's intended security texture. The offcard computes the MAC of the data packet using the sessionMAC key and a chained Initialization Vector which starts at 0s but gets updated to a new value, the details of which I shall for now blissfully ignore so as to preserve my sense of humor.
I repeat, the second message that the offcard send to the card is still not encrypted.
The card now receives the second message. The card now parse the components of this second message:
4 bytes command
84 82 03 001 byte length
8 bytes cryptogram
8 bytes MAC tag
The last 8 bytes MAC tag attached in this message is a calculation of the first 13 bytes. At the time of writing, it is impossible to compute the MAC tag that includes the MAC tag. If you can do it in any given arbitrary data then you must be from the future. So, yes the MAC is distinct separate from the piece of data it refers to.
The card performs its own MAC calculation of this 13 bytes and it must match the MAC tag attached in the message. Remember, this MAC calculation uses the sessionKeyMAC and a chained Initialization Vector which starts at 0's and gets updated, the details of which I try to blissfully ignore for now to hold unto my sense of well-being. But we can begin to see here, that the value of the IV takes on different succeeding values based on input data and these values at any moment must match both in the card and in the offcard. I think of IV as some sort of cryptographic umbilical cord of the SCP02 session. Take for example, I made some tinkerings, by calling a method inside the applet that resulted to an update of the IV of the card and this broke the session on the immediate next offcard transmission giving me 69 82 response status. It is easy to dismiss this error and usually we redo the session handshake (ie /atr) to setup secure channel again and consider it a glitz. I did not consider it a glitz and I resolve with all my might to reproduce the conditions until I found the root cause. It was the Initialization Vector getting out-of-sync.
Here is some things to note of. During INITIALIZE_UPDATE, the card proves its identity/ENC to the offcard. This proof only proves to the offcard that the card has same ENC key. Take note, a proof is not instantaneously bidirectional. It occurs in discreet stages. First, the offcard knows that the card is legit. But the card still does not know anything about the offcard. Next, during the second message the card now nows that the offcard's ENC MAC is legit. Now the legitimacy of identity is via 3 keys ENC, MAC and DEK. In the EXTERNAL_AUTHENTICATE, the offcard proves its ENC MAC key to the card. So in EXTERNAL_AUTHENTICATE, both entities are certain that they share the same ENC key that:
The offcard is certain that the card has the ENC key
The card is certain that the offcard has the MAC key
Furthermore, a successful EXTERNAL_AUTHENTICATE also proves that both have the same MAC key. Crossing out but retaining this partially incorrect statement because the proof of MAC key is when MAC tagging occurs. The card's response are not tagged if the offcard did not set the RMAC bitfield.
Here is the second communication:
Everything is in the clear and nothing is encrypted. I marked the host_cryptogram in ^^ caret. I marked the MAC tag in ** asterisk. At the close of EXTERNAL_AUTHENTICATE phase, the card simply response with 90 00 ok status code.
It is curious, that the card haven`t proven yet to the offcard that it has the MAC key. Well, there is no need because in this scenario so far the card never attaches a MAC tag in its response data. Why? Because, the offcard chooses the texture of the secure channel and it only sets the two bitfields for MAC and ENC. As a result, every response of the card has no MAC attached to it. Every response of the card is also not encrypted. At this current texture, It is the data from offcard to card that gets encrypted. But the response from card to offcard travels in plain. (The term texture is my own naming convention to mean a particular mode or setting i call it out of spontaneity, texture.)
Things to note:
Possession of ENC key is used by card to introduce itself
Possession of MAC key is used by offcard to introduce itself in the case where the second message is not encrypted
Possession of ENC and MAC key is used by offcard to introduce itself in the case where the second message is encrypted
The chained IV is per session and its next hopping value is influenced by:
MAC key and generated session_MAC key
data
I think of the chained IV as like the Bluetooth FHSS.
Last updated
Was this helpful?