[Muscle] load file DAP

Sun Sep 28 23:41:16 PDT 2008

The SD transitions to the life cycle PERSONALIZED automatically once all keys needed for full operation are populated for this SD. Example: SD has mandated DAP privilege --> RSA public key and all secure channel keys mus be populated; delegated management --> secure channel keys and token verification key must be populated.. As long as the SD has not all the keys needed, it will use the secure channel services of its associated SD.

With the ongoing GP work it is planned to have a possibility not to have the transition automated, but do it manually once all keys are there.

Message: 1
Date: Fri, 26 Sep 2008 12:15:55 -0700
From: Peter Williams <home_pw at msn.com>
Subject: RE: [Muscle] load file DAP
To: MUSCLE <muscle at lists.musclecard.com>
Message-ID: <BLU132-W3506F01525D17AC90E09AD92470 at phx.gbl>
Content-Type: text/plain; charset="iso-8859-1"

talking of seucre channels to security domains, http://www.globalplatform.org/uploads/GPC_v2%202-B_RAM_Over_HTTP_public_review.pdf

Note how, just like EAP methods did things like EAP-TTLS that take SSLmessages and use them on conenctionless bearer to allow a PC/TPM to authenticate to a switch port (supported by a radius/AAA server), here we see TLS being use for GP secure channels.

note how TLS ciphersuites signaling/negotiation is being intelligently applied. Not every ciphersuite has to be RSA, with PKI! It can also be a ciphersuite tuned to PSK management regimes (like those use in the key management concept of GP2.) I can see how this all works fine with DAP, and receipts.

I used to have a PIV card, where the PIV "applets" were programmed natively (no javacard), and the card also had GP (again, native C, not javacard) so the card could be remotely adminsitrated, using standard provisioning/admin tools based on ICC opcodes.I can easily see them adding a TLS message processor to that GP code to implement another variant of securechannel, and then using TLS specific crypto primitives from the cryptomodule in the base ICC.

From: home_pw at msn.comTo: muscle at lists.musclecard.comSubject: RE: [Muscle] load file DAPDate: Mon, 28 Apr 2008 11:20:42 -0700

Do any of the following facts sound plausible - for a new GP 2.01 era card with installed SD? - one binds to the SD's AID- one does the security handshake, using keys of the card issuer - one does putkey(DES=0x81) into the SD instance - one does a 2nd security handshake, using keys of the SD now - one does putkey(RSA=0xA1)  - one binds and does security handshake with card issuer  - load uses gpshell to load up the firmware, where gpshell calculates the RSA signature(s) and SHA dynamically - Cardissuer with have SD check the RSA signature, at the end of load? Wondering if I need to SetStatus at any point, manually on the SD's state.

> From: home_pw at msn.com> To: muscle at lists.musclecard.com> Subject: Re: [Muscle] load file DAP> Date: Fri, 25 Apr 2008 18:21:05 -0700> > Even more incredibly, I cleaned out an old filing cabinet, while moving > offices. Found the DODCAC/Martsoft v2.01 manual on the DAP support in the GP > 2.01 card. I'll go play, now I have some technical counsel.> > --------------------------------------------------> From: "Karsten Ohme" <widerstand at t-online.de>> Sent: Thursday, April 17, 2008 5:05 PM> To: "MUSCLE" <muscle at lists.musclecard.com>> Subject: Re: [Muscle] load file DAP> > > Peter Williams schrieb:> >> Guess I get to do it myself! If I recall the GP model, this is what I > >> need to do with GPShell> >>> >> 1. use openssl lib to create PEM-era private/public key files (wow, it > >> 1985 I think I first hit PEM, learning it along with > >> RSA/DES/CBC/countermode from the person drafting PEM in IRTF (even before > >> it hit IETF!). Its been around a while!)> >>> >> 2) 1. use GPSHEL!
 L load dm key of the openssl RSA keyfile into the app > >> domain applet, version=1 index=1> >>> >> 3) create the muscle applet load file from the cap, affixing the > >> appropriate RSA 1024bit signature. Can gpshell do this, on the fly or > >> statically?> >> > Not GPShell, the Global Platform library should be able to do this. But I > > never got a card working with the a security domain. Either the > > specification is not clear enough, the cards are buggy or I do something > > wrong over and over again.> >> > Regards,> > Karsten> >> >>> >> 4) load and install the signed applet, where its security domain is the > >> APP security domain AID (not the more usual card issuer)> >>> >> Doing all this, I think the load flow is: Upon detection of 1 or more > >> signature blocks in the load file, the card issuer is supposed to invoke > >> the app SD denote in the load for load APDU to verify the crypto - where > >> the AppSD knows the crypto is RSA and the key is RSA, the key ind!
 ex 1, > >> and the signature block has endian format X.> >>> >>> >> --
------------------------------------------------> >> From: "Peter Williams" <home_pw at msn.com>> >> Sent: Monday, April 14, 2008 11:04 AM> >> To: "MUSCLE" <muscle at lists.musclecard.com>> >> Subject: Re: [Muscle] load file DAP> >>> >>> I've managed to locate (somewhat incredibly) 5 virgen USB tokens that - > >>> presumably as they are in their original static-proof bags - still have > >>> the manufacturer's app security domain applet on the card - in addition > >>> of the card issuers SD. (Typically, during post-manufacturing we removed > >>> the app SD , to free up space to load and init the muscle applet.)> >>>> >>> What I do not have is any technical documentation and all the my people > >>> contacts have long since left the javacard startup company for greener > >>> pastures.> >>>> >>> Anyone want to play with some of them, to test GPShell and ensure its > >>> 2.01 era delegated loading (via RSA) is solid?> >>>> >>> --------------------------------------------------> >>> Fro!
 m: "Karsten Ohme" <widerstand at t-online.de>> >>> Sent: Saturday, April 05, 2008 4:43 AM> >>> To: "MUSCLE" <muscle at lists.musclecard.com>> >>> Subject: Re: [Muscle] load file DAP> >>>> >>>> Peter Williams schrieb:> >>>>> 1. Has anyone used GPShell to load an RSA public key into an > >>>>> _issuer's_ security domain of a 201 card, so one can use the GPShell > >>>>> to send a DAP hash and signature for the load file?> >>>>> >>>> I think this does not work. I have tried a lot with different cards, > >>>> but I had no success. So, there might be compatibility problems, the > >>>> cards do to support it after all or the specification is not clear > >>>> enough. You can play with the code base, would be very interesting to > >>>> me, if you get it working.> >>>>> >>>> Karsten> >>>>> 2. has anyone tested the use of SHA1 by itself for a LOAD DAP?> >>>>> 3 If I half remember right, only a security domain OTHER than the > >>>>> card manager SD can verify either a DESCBC or an RSA DAP (g!
 iven its > >>>>> knows the verification key, and knowledge that the si
gnature is either > >>>>> RSA or DESCBC).> >>>>> ------------------------------------------------------------------------> >>>>>> >>>>>> >>>>> _______________________________________________> >>>>> Muscle mailing list> >>>>> Muscle at lists.musclecard.com> >>>>> http://lists.drizzle.com/mailman/listinfo/muscle> >>>>> >>>> _______________________________________________> >>>> Muscle mailing list> >>>> Muscle at lists.musclecard.com> >>>> http://lists.drizzle.com/mailman/listinfo/muscle> >>>>> >>> _______________________________________________> >>> Muscle mailing list> >>> Muscle at lists.musclecard.com> >>> http://lists.drizzle.com/mailman/listinfo/muscle> >>>> >> _______________________________________________> >> Muscle mailing list> >> Muscle at lists.musclecard.com> >> http://lists.drizzle.com/mailman/listinfo/muscle> >>> >>> >> > _______________________________________________> > Muscle mailing list> > Muscle at lists.musclecard.com> > http://lists.drizzle.com/mailman/listinfo/muscle>!
  >

Express yourself wherever you are. Mobilize!
_________________________________________________________________
See how Windows connects the people, information, and fun that are part of your life.
http://clk.atdmt.com/MRT/go/msnnkwxp1020093175mrt/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drizzle.com/pipermail/muscle/attachments/20080926/e64f827a/attachment-0001.html

------------------------------

_______________________________________________
Muscle mailing list
Muscle at lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

End of Muscle Digest, Vol 55, Issue 7
*************************************