The following will talk about, at a fairly high level, what has been worked and what needs to be done to add scp03 support to our TMS system. (Now that we are mostly done, updates will be provided to some of the items to come.)

Things done previously several months back before starting full blown development: (Update: Of course now development has completed for this release)

• SCP03 is a specification from Global Platform that is based upon secure channel creation based upon AES symmetric keys. The exact spec can be found by searching the Global Platform web site. https://www.globalplatform.org/

  • The title is : Secure Channel Protocol '03' Card Specification v2.2 – Amendment D. The reason why it can’t be linked directly is because the site requires you run through a couple of hoops to get the various documents.

• Obtained some test scp03 cards. (G&D Smart Cafe 6.0)

• Was able to generate a scp03 based secure channel using the 3rd party tool Global Platform Pro.

• Began working on some preliminary code for TMS:

  • Completed the detection code such that can automatically recognize a scp03 enabled card.

  • Began work on the AES-CMAC algorithm, which is used all over the place in scp03. This algorithm is specified in:

    • NIST SP 800-38B [10]. This algorithm is heavily involved in creating MACS or message authentication codes. (update, this algorithm was successfully implemented in Java code, using JSS functionality).

• Although the spec call for AES session keys of various sizes, we have decided to begin by supporting the most common size of 128 bit AES keys for the secure channel session keys.

• Complete the AES-CMAC algorithm implementation using Java only JSS code. (Update completed)

  • This will require a simple bug fix to JSS to allow using AES keys for sym key operations. Right now a legal AES key is being misidentified as RC2 by JSS. (Update JSS fixed to allow AES sym key operations)

• Decide upon an implementation (i) to support for scp03: (update, decided on and implemented mutual auth, MAC, and ENC on the apdu’s. This is the standard implementation for secure processing).

  • We will probably want at a minimum mutual authentication, message integrity (MACing) and, message confidentiality (encryption).

  • The one thing that is optional is the use of the R-MAC scheme which does a mac upon return apdu’s. This requires one more type of session key to be generated other than the 3 standard enc, mac, and dek keys. ***This will be the S-RMAC session key. Code will be needed in TKS to generate this key. Also the RMAC operation will have to be implemented in code to act upon the desired message data.(update, RMAC was not yet implemented in the first version.)

• From here it is just a matter of implementing the various MACing and encryption methods upon the apdu commands going back and forth. The end result will be a secure channel upon which to communicate with the token. (Update: completed)

• This will require generating the various session (AES) keys required to perform these operations. It will also require processing the various host and card challenges needed to provide mutual authentication. The code will be similar but different than previous versions of the SCP we have already implemented based upon the what is stated in the spec and the fact we are using AES keys now in scp03.(Update, completed)

• This work will require work to both TPS and TKS subsystems. In CS 9.1, we made it possible to perform a bunch of sym key manipulations in pure Java / Jss code, so this work should not require resorting to native JNI code this round. (Update: Entire implementation of SCP03 was completed entirely using pure Java code while making use of JSS for the cyrpto functions.)

• Also, the scp03 spec calls for use of the KDF nist sp800, which we did a version of for CS 9.x. This may have to be enhanced since in scp03, since the spec calls for the use of the CMAC hashing (discussed earlier) , where in scp02 and scp01, we used the HMAC for this hash. (Update: This was completed.)

• Once we have a secure channel to a card we must do the following major things:

• Do what is required to perform an end to end format operation, which will leave us with an instantiated applet residing on the token. We can try this out with the current gp211 applet to just see if we can get an applet written, to the card, before worrying about GP221. (Update: It turns out that the current GP211 applet we shipped with SCP02 works for SCP03)

• Do what is required to perform a full enrollment on the token. We can try this with token side keygen of the encryption private key to factor out (temporarily) the server side keygen and and subsequent private key injection into the token complications. (Update: both token side and server side keygen completed)

• Do what is required to use the server side keygen scheme for the encryption private key and have it injected onto the token. Note that the enrollment steps may require the full gp221 applet support, if needed, as described below. (Update: current gp211 applet worked fine)

• The end result will be a token with the required certificates and keys.

• Perform some testing where we use the token to perform real cryptographic operations using Firefox and supported email clients for smime.

• Figure out if we need a new applet to go along with scp03, which is an amendment to the GP 2.2.1 specification. (Update no new applet needed)

• Applet work will also probably contain work to be able to inject the private key onto the token based on the AES key encryption key we will be using. Right now this is done with RSA. (Update: It turned out that no mod to the applet was needed to inject the private key. The KEK key is AES now, but the token knows how to handle it, so it worked fine.)

• Perform tasks needed to support legitimate symmetric key changeover

  • Changes to the command line tool tkstool required to create AES based master keys on the soft token or hsm. (Update: We have a bug for this problem. Not yet completed. It turns out that the G&D SC 6.0 card actually needs a DES based master key. The SC 7.0, which we also provided support for, needs an AES master key. The plan for now, is to generate this key with 3rd party tools, like those available on the various HSM models. For master keys in the NSS software token, we have an unsupported but still working NSS tool called /usr/lib64/nss/unsupported-tools/symkeyutil, which can be used to generate software AES master keys until we fix the official tkstool application to be able to handle AES master keys.)

• Do what is needed in TMS code to support symmetric key changeover. This will most probably require some new code, since the key upgrade procedure is known to change slightly from version to version. The 3 new static keys to go on the token need to be wrapped up and protected before being sent to the token. This scheme will most probably differ here. (Update: minor changes were needed and it was implemented successfully)

• SCP03 cards, and previous versions are detected automatically at this point and acted upon, by TPS.

• This code snippet of the TKS config file shows config for the two supported tokens, the G&D 6.0 and 7.0

  • What we have there is a way to specify the "key diversification" method of a given class of token. This refers to the first step that takes place when ultimately leading up to a finished session key. There are multiple types of diversification available: There is the older visa2, which is not used here or the emv method. Also one token prefers no diversification step. Also note that the configuration allows us to specify a diversification method for the ver1 or "developer" keyset and the method for all subsequently upgraded versions of the token’s keyset.

  • Also note that for each token we can specify what type of key represents the master key, DES3 or AES.