RE: RE: [Muscle] load file DAP

[Alexej Muehlberg]

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 <[EMAIL PROTECTED]>
Subject: RE: [Muscle] load file DAP
To: MUSCLE 
Message-ID: <[EMAIL PROTECTED]>
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: [EMAIL PROTECTED]: [EMAIL PROTECTED]: 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: [EMAIL PROTECTED]> To: muscle@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" 
> <[EMAIL PROTECTED]>> Sent: Thursday, April 17, 2008 5:05 PM> To: "MUSCLE" 
> > 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

RE: [Muscle] load file DAP

[Peter Williams]

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: [EMAIL PROTECTED]: [EMAIL PROTECTED]: 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: [EMAIL PROTECTED]> To: muscle@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" 
> <[EMAIL PROTECTED]>> Sent: Thursday, April 17, 2008 5:05 PM> To: "MUSCLE" 
> > 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 GPSHELL 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 index 1, > >> and the signature 
> block has endian format X.> >>> >>> >> 
> --> >> From: "Peter Williams" 
> <[EMAIL PROTECTED]>> >> Sent: Monday, April 14, 2008 11:04 AM> >> To: 
> "MUSCLE" > >> 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 stati

RE: [Muscle] load file DAP

[Peter Williams]

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: [EMAIL PROTECTED]> To: muscle@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" 
> <[EMAIL PROTECTED]>> Sent: Thursday, April 17, 2008 5:05 PM> To: "MUSCLE" 
> > 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 GPSHELL 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 index 1, > >> and the signature 
> block has endian format X.> >>> >>> >> 
> --> >> From: "Peter Williams" 
> <[EMAIL PROTECTED]>> >> Sent: Monday, April 14, 2008 11:04 AM> >> To: 
> "MUSCLE" > >> 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?> >>>> >>> 
> --> >>> From: "Karsten Ohme" 
> <[EMAIL PROTECTED]>> >>> Sent: Saturday, April 05, 2008 4:43 AM> >>> To: 
> "MUSCLE" > >>> Subject: Re: [Muscle] load file 
> DAP> >>>> >>>> Peter Williams schrieb:> >>>>> 1. Has anyone used GPShell to 
>

Re: [Muscle] load file DAP

[Peter Williams]

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" <[EMAIL PROTECTED]>
Sent: Thursday, April 17, 2008 5:05 PM
To: "MUSCLE" 
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 GPSHELL 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 index 1, 
and the signature block has endian format X.



--
From: "Peter Williams" <[EMAIL PROTECTED]>
Sent: Monday, April 14, 2008 11:04 AM
To: "MUSCLE" 
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?


--
From: "Karsten Ohme" <[EMAIL PROTECTED]>
Sent: Saturday, April 05, 2008 4:43 AM
To: "MUSCLE" 
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 (given its 
knows the verification key, and knowledge that the signature is either 
RSA or DESCBC).

 


___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle


___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle


___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle


___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle




___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle


___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] load file DAP

[Karsten Ohme]

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 GPSHELL 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 index 1, 
and the signature block has endian format X.



--
From: "Peter Williams" <[EMAIL PROTECTED]>
Sent: Monday, April 14, 2008 11:04 AM
To: "MUSCLE" 
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?


--
From: "Karsten Ohme" <[EMAIL PROTECTED]>
Sent: Saturday, April 05, 2008 4:43 AM
To: "MUSCLE" 
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 (given its 
knows the verification key, and knowledge that the signature is 
either RSA or DESCBC).
  



___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle


___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle


___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle


___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle




___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] load file DAP

[Peter Williams]

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 GPSHELL 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?


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 index 1, and the 
signature block has endian format X.



--
From: "Peter Williams" <[EMAIL PROTECTED]>
Sent: Monday, April 14, 2008 11:04 AM
To: "MUSCLE" 
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?


--
From: "Karsten Ohme" <[EMAIL PROTECTED]>
Sent: Saturday, April 05, 2008 4:43 AM
To: "MUSCLE" 
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 (given its knows the 
verification key, and knowledge that the signature is either RSA or 
DESCBC).

 

___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle


___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle


___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle


___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] load file DAP

[Peter Williams]

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?


--
From: "Karsten Ohme" <[EMAIL PROTECTED]>
Sent: Saturday, April 05, 2008 4:43 AM
To: "MUSCLE" 
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 (given its knows the 
verification key, and knowledge that the signature is either RSA or 
DESCBC).

 

___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle


___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle


___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] load file DAP

[Karsten Ohme]

Peter Williams schrieb:
out of interest, what simple win32 openssl command is required to create 
the file used by GPShell's put_dm_keys?
 
I tried the obvious choice, but it GPShell PEM_read_PUBKEY call fails to 
read back the public key from this keypair -
 
genrsa -out c:\foo.pem -des -passout pass:password 1024


No, with this you only create a private keypair DES encrypted. The 
public key is implicitly known.


After generating the private key extract the public key with this:

openssl rsa -in foo.pem -pubout -out foopub.pem

Regards,
Karsten

 
 
 
 
*From:* Peter Williams 

*Sent:* Friday, April 04, 2008 5:54 PM
*To:* MuscleCard Mailing List 
*Subject:* [Muscle] load file DAP

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?
 
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 (given its knows the 
verification key, and knowledge that the signature is either RSA or DESCBC).
 




___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle




___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle


___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] load file DAP

[Karsten Ohme]

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 (given its knows the 
verification key, and knowledge that the signature is either RSA or DESCBC).
 





___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle


___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

Re: [Muscle] load file DAP

[Peter Williams]

out of interest, what simple win32 openssl command is required to create the 
file used by GPShell's put_dm_keys?

I tried the obvious choice, but it GPShell PEM_read_PUBKEY call fails to read 
back the public key from this keypair -

genrsa -out c:\foo.pem -des -passout pass:password 1024




From: Peter Williams 
Sent: Friday, April 04, 2008 5:54 PM
To: MuscleCard Mailing List 
Subject: [Muscle] load file DAP


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?

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 (given its knows the verification 
key, and knowledge that the signature is either RSA or DESCBC).






___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle
___
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle