Researching this one right now. We need this one.

Global Platform and Secure Channel Protocol version 02 notes:

From performing some reasearch, the following became apparent:

1. Although the latest GlobalPlatform version out is 2.2.X, it looks like that version 2.1.1 is the newer version
   that is actually supported on most of the available smart cards. For instance the important Safenet SC650, which is
   our target, claims to suport GP only up to 2.1.1.

2. GP 2.1 does in fact suport a newer Secure Channel protocol called SCP 02. Currently we support GP 2.0.1 which is becoming
   raplidly deprecated. GP 2.0.1 also uses Secure Channel prococol SCP 01, which is becoming deprecated as well.

3. GP 2.2 takes the secure channel protocol even further by introducing the notion of PKI (public and private) keys instead of
   the symmetric keys previously supported.

The implementation of the GP/Secure Channel standard involves several pieces of our Token Management System:

• TPS makes use by making APDU based calls down into the "Card Manager" applet and our own "CoolKey" applet.

The TPS also makes calls to TKS to create session keys needed for the secure channel protocol.

• TKS is responsible for creating and deriving the various session keys called for. It also deals with the "master key", from which

the session keys are ultimately derived.

• The coolkey applet, makes calls into the GP java framework to do various tasks like creating a secure channel and getting information

from the card back to the caller with APDUs.

1. What I believe we should do to conform GP 2.1 and SPC 02 is the following:

2. Port the current applet to compile against the GP 2.1 framework. The GP 2.0.1 stuff is available though deprecated. This first step will be

useful to clean up any differences between the API.

• Begin working on SCP version 2.
  Since version 2 and version 1 are of similar philosophy, this should not be a huge undertaking. Both versions call for both the host entity and

for the card to create a selection of session keys. This is for each side to prove to the other that they have the master key information needed to create
the same session keys. SCP 02 may call for some slightly different or a different number of session key, but the idea is the same. The implication of this
is that we can make some relatively minor modifications to the existing TPS and TKS to support version 02. Also it may not be a large effort to be able to
dynamically suport both versions of the Secure Channel Protocol along with both versions of the GP, 2.0.1 and 2.1.1. A data point in favor of this is the code
to the readily available "gpshell" utility. This utility allows the user to write some simple scripts to talk to a smart card. Some of the things that can be done
are to create secure channels to the card and to load onto and to delete applets from the token. The code for this utility has some relatively straightforward
branching conditions to be able to support both GPs and both SCP's. I feel we can make similar mods to both TPS and TKS to do this. For each SCP version there
are different flavors or implementations of the SCP. Differences here consider the number of session keys to generate and other security constraints upon the connecton.
Here we should make sure we implement the proper flavors.

Both SCP 01 and 02 kick off the secure channel by issuing an "InitializeUpdate" command followed by the "ExternalAuthenticate" command. This accomplishes what as known as
mutual authentication. A good portion of the differences between the two protocols involve the operation of these two APDU commands in how they are issued and how the results
from the token are interpreted.

• Modify TPS to be able to talk GP 2.1 and SCP 2. Some of the APDU's may be slightly altered for this task.

• Modify TKS to be able to derive any new types of session keys called for by the SCP 02.

• Perform some end to end tests with ESC to make sure we can create a secure channel and format and enroll a GP 2.1.1 token with SCP 02.

• The tool gpshell can be used at intermediate steps to deal directly with the card to make sure things are progressing correctly.

• Once we get 2.1 working, we can go back and make sure that 2.0.1 and SCP 01 can still work on the same token if supported.

• Since a given card can ce queried to see what kind of GP it supports and what kind of SCP it supports, we could dynamically with TPS create the highest

version of SCP available to that card.

1. Later we can look at GP 2.2 when that starts gaining momentum on available tokens. The change this time will be much larger and the changes to our software may be more involved.

Notes:

I have taken an enrolled SC650 and used the tool "gpshell" to create secure channels to the card using both GP 2.0.1 and GP 2.1.1.
An interesing ovservation is that even when requesting GP 2.1.1, since the card can be quried to find out the supported SCP, the SC650 is returning
01 for the supported SCP. Therefore in this case we are connecting to the token using GP 2.1.1 but making a SCP 01 secure channel. More investigation
will have to be done here. We want to be able to have a token that can actually do a SCP 02 secure channel.

Here is a sample output of a run of gpshell for the SC650 in 2.0.1 mode:

mode_201
enable_trace
establish_context
card_connect

• reader name OmniKey CardMan 3121 00 00

select -AID a0000000030000
Command --> 00A4040007A0000000030000
Wrapped command --> 00A4040007A0000000030000
Response <-- 6F458408A000000003000000A539732F06072A864886FC6B01600C060A2A864886FC6B02020101630906072A864886FC6B03640B06092A864886FC6B0401159F6E01019F6501FE9000
open_sc -security 1 -keyind 0 -keyver 0 -mac_key 404142434445464748494a4b4c4d4e4f -enc_key 404142434445464748494a4b4c4d4e4f // Open secure channel
Command --> 8050000008EC881BBABDC6606600
Wrapped command --> 8050000008EC881BBABDC6606600
Response <-- 00000000000000000000FF012C0429F244854E59832428BE4029E2AA9000
Command --> 848201001015E629E7F2B99B71DA90016E0C1EBFAA
Wrapped command --> 848201001015E629E7F2B99B71DA90016E0C1EBFAA
Response <-- 9000
get_status -element 80
Command --> 80F28000024F0000
Wrapped command --> 84F280000A4F007D71B41E3348D2BC00
OP201_get_status() returns 0x80100016 (Unknown error: 0xFFFFFFFF80100016)

Here mode_201 is requested and the card manager applet is selected before attempting the secure channel.
At the end it tries to get the SC650 to give it a list of applets. For some reason this apdu is not accepted on this card.

Here is a sample of a run of gpshell for the SC650 in 2.1 mode:

mode_211
enable_trace
establish_context
card_connect -readerNumber 3

• reader name OmniKey CardMan 3121 00 00

select -AID a000000003000000
Command --> 00A4040008A000000003000000
Wrapped command --> 00A4040008A000000003000000
Response <-- 6F458408A000000003000000A539732F06072A864886FC6B01600C060A2A864886FC6B02020101630906072A864886FC6B03640B06092A864886FC6B0401159F6E01019F6501FE9000
open_sc -security 1 -keyind 0 -keyver 0 -kek_key 404142434445464748494a4b4c4d4e4f -mac_key 404142434445464748494a4b4c4d4e4f -enc_key 404142434445464748494a4b4c4d4e4f // Open secure channel
Command --> 80CA006600
Wrapped command --> 80CA006600
Response <-- 6631732F06072A864886FC6B01600C060A2A864886FC6B02020101630906072A864886FC6B03640B06092A864886FC6B0401159000
Command --> 805000000869398C091DF1906100
Wrapped command --> 805000000869398C091DF1906100
Response <-- 00000000000000000000FF01563F3D8563EA9274CF65125DA6F406849000
Command --> 848201001082EE8A2FA3C4EA17BD90D6CA692C6053
Wrapped command --> 848201001082EE8A2FA3C4EA17BD90D6CA692C6053
Response <-- 9000
get_status -element 10
Command --> 80F21000024F0000
Wrapped command --> 84F210000A4F008F6F8DABBC21B25800
Response <-- 6982
GP211_get_status() returns 0x80206982 (Unknown ISO7816 error: 0x6982)

During this run, inspecting the optional debug info tells us that it really requested a SCP 01 secure channel:

22/11 11:23:59 -get_secure_channel_protocol_details in GlobalPlatform.c at line 2730 : end RV(0x0)
22/11 11:23:59 +mutual_authentication in GlobalPlatform.c at line 5649 : start
22/11 11:23:59 Secure Channel Protocol: 0x01
22/11 11:23:59 Secure Channel Protocol Implementation: 0x15

Sending this to July. We want the current secure channel protocol and basic token operations working first.

After discussions, decided to move this to 10.2.3.

Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1097352 (Red Hat Certificate System)

Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1097352 (Red Hat Certificate System)

Per 10.2.2 Triage meeting of 02/24/2015: 10.2.3

Per Dogtag 10.2.x TRIAGE meeting of 04/28/2015: (Tech Preview Feature)

Per CS/DS meeting of 06/08/2015: 10.2.6

Progress with the GP211 applet:

One of the things wanted to do was provide a coolkey applet based on teh gp211 libraries vs the current gp201 ones. We have had access to some code provided by the community that accomplishes this:

Things done:

1. Figured out how to compile this new code.
2. Tested the new applet with the current TPS. Initially this failed but I found a small bug in the "non server side keygen" case and addressed it.
3. Tested an enrolled token with BobR's "smartcard" utility that exercises the basic crypto operations of the card with respect to signing and encryption.
4. Note: The first cut of this applet will be RSA only, we can port the ECC stuff over as a later ticket.
5. Tried the token with Firefox to negotiate to a client auth protected site. The basic SSL handshake succeeded. The server in question then failed the session due to an auth issue. The point was to test out the SSL portion of the negotation which appears to work fine.
6. Had BobR look over the code. He thinks it is ok but wanted me to take another pass to see if there are any bad memory issues that could cause damage to the card. Another careful pass revealed that nothing new bad was added and actually one possible memory leak was addressed by moving an object allocation to the constructor instead of on the fly.
7. One very small one line fix was needed in TPS to get the enrollment working. Patch will be on review shortly.
8. Made some minor changes to the Makefile to put the applet into a form that TPS can work with it with no changes.

Things to do:

1. Work with the build infrastructure to make the build easy.
2. Create new branch in coolkey to host the code.
3. Get official builds to ship with TPS or to have available as download.

Code checked into COOLKEY_GP211_BRANCH branch for gp211/scp02.

Official builds requested and done.
Will install this new applet into TPS as a beta applet choice.

Code checkin:

commit 158ae4bfa03c56c02dcba9066c4dc3ff1806e6a0
Author: Jack Magne jmagne@localhost.localdomain
Date: Thu Jun 25 11:45:13 2015 -0700

Add GP211 applet and latest GP201 applet for RSA.
Ticket # 793:  Add support for Secure Channel Protocol 02
Properly select the coolkey applet in the "getAppletVersion" routine.
For some reason the gp211 applet revealed this issue.
Tested to work with both gp211 scp02 card and gp201 scp01 card.

Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new
issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.

This issue has been cloned to GitHub and is available here:
https://github.com/dogtagpki/pki/issues/1360

If you want to receive further updates on the issue, please navigate to the
GitHub issue and click on Subscribe button.

Thank you for understanding, and we apologize for any inconvenience.