[Pki-devel] [pki-devel][PATCH] 0024-Ticket-TPS-Rewrite-Implement-Secure-Channel-Protocol.patch

[Christina Fu]

APDU.java
*I don't see getCalculateSingleDesBeforeMac() or 
setCalculateSingleDesBeforeMac() being used. calculateSingleDesBeforeMac 
seems to be hard-coded in every APDU.
* it seems the only difference between the existing secureMessage() and 
your secureMessageSCP02() is very miner:
   if (rem == 0) {
+
+            padNeeded = 8;
instead of
                padNeeded = 0;
Couldn't this be handled by modifying the existing function?


On 02/23/2015 10:36 PM, John Magne wrote:
> Subject: [PATCH] Ticket: TPS Rewrite: Implement Secure Channel Protocol 02
>   (#883).
>
> First cut of gp211 and secure channel protocol 02 for tokens.
>
> Allow token operations using a GP211 token over secure channel protocol 02.
>
> This patch supports the following:
>
> 1. Token operations with a GP211 card and SCP02 protocol, implementation 15.
> 2. Token still supports GP201 cards with SCP01.
> 3. SCP02 tested with SC650 gp211/scp02 card.
> 4. Formatting ,e nrollment, and pin reset tested to work.
> 5. Symmetric key changeover upgrade and downgrade tested to work.
> 6. APDU security methods of CMAC and Encryption supported, as well as the combination
> of the two.
>
>
> Things still to do:
>
> 1. Right now the SCP02 support has been tested with the current gp201 applet and
> enrollment and formatting works just fine. We need to modify and compile the applet
> against the GP211 spec and retest to see if any further changes are needed.
>
> 2. The nistSP800 key derivation stuff is not completed for the SCP02 protocol. Some
> of the routines are self contained vs similar SCP01 ones. We have another ticket to
> complete the nistSP800 support from end to end. This work will be done for that ticket.
>
> 3. One of the new scp02 deriviation functions can make use of a new NSS derive mechanism.
> As of now this work is done by simple encryption, this can be done later.
>
> 4. The security APDU level of "RMAC" is not supported because the card does not support it.
> It could have been done to the spec, but it having the card to test is more convenient and there
> were more crucial issues to this point.
>
> 5. Right now the security apdu level is set hard coded to the max supported level for scp01 and 02.
> Need to make that more configurable, although there is no reason to downgrade the apdu security.
>
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20150224/6f74270c/attachment.htm>