If NIST CSL wanted to implement a model IFD that wraps APDUs in GP secure messaging conventions, and explains how to configure a common JavaCard (e.g. the IBM/Gemplus BlueZ, or IBM JCOP cards) with some SCP01 keysets, this would be a valuable contribution, IMHO. This features comes with some commercial IDEs, note.
Peter.
From: Clement Seveillac <[EMAIL PROTECTED]> Reply-To: MUSCLE <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: [Muscle] INITIALIZE UPDATE & secure channels support Date: Sat, 20 Mar 2004 12:21:27 -0500
Hi folks,
We would like to experiment smart card scenarios where the client and the card talk over an insecure channel (e.g. wireless). We are quite interested in the Secure Channel Protocol '01' defined in GlobalPlatform (aka Visa OpenPlatform) card specifications [1] [2]. This protocol modifies APDUs, using some pre-established symmetric keys on both sides, to secure the original APDUs with MAC checks and optional encryption.
[1] http://www.globalplatform.org/showpage.asp?code=cardspec [2] some slides: http://www.cs.utexas.edu/users/jurgens/Lectur16.pdf
Unfortunately the Muscle API, which we would like to use, does not seem to implement (yet?) the necessary instructions for this Secure Channel Protocol (let's call it SCP 01).
Indeed, SCP 01 flow can be drawn like this:
host card
---SELECT Security Domain------>
<-------------SELECT Response---
and the SCP 01 establishment itself: (with parameters:)
---INITIALIZE UPDATE-----------> Key ID + host challenge
<----INITIALIZE UPDATE Response- 'signed' host challenge + card challenge
---EXTERNAL AUTHENTICATE-------> Security level (MAC or/and encryption) + signed card challenge + MAC
<---EXT AUTHENTICATE Response--- 90 00 if success or 63 00 for failed authentication
Then both sides have keys to check and encrypt/decrypt the encapsulated and secured APDUs they will now send to each other.
...But the Muscle API v1.3.0 seems to implement only EXTERNAL AUTHENTICATE for the moment (page 31 of the API doc [2]), so we only get one-side authentication and no confidentiality.
[2] http://tinyurl.com/yw8hk , which points to: http://216.239.57.104/search?q=cache:v5YGkgedG6oJ:www.linuxnet.com/musclecard/files/muscle-api-1.3.0.pdf+musclecard+api&hl=en&ie=UTF-8#32
SCP 01 is already used by several Javacard vendors SDK to load applets, but then you have to use their proprietary code (not often portable) for this, whereas SCP01 is supposed to be a standard, available not only for secure Javacard applet loading but for any scenario when you could need a secure channel...
Could you tell me if you plan or if you would like to implement this protocol in the Muscle project, or even if I may help implement this? SCP 01 is pretty well defined in [1], and the crypto behind it is not too complicated...
Many thanks in advance, -- clem _______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.drizzle.com/mailman/listinfo/muscle
_________________________________________________________________
Find a broadband plan that fits. Great local deals on high-speed Internet access. http://click.atdmt.com/AVE/go/onm00200360ave/direct/01/
_______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.drizzle.com/mailman/listinfo/muscle
