smartcardjavacardglobalplatformsecuritydomain

Problem Loading Signed CAP file directly to Supplementary Security Domain


My target is to have an independent supplementary security domain (SSD) that I can directly load a CAP file into it. To that end, I instantiate an SSD from the package A0000001515350 with AID A000000151535041 and privilege DAP Verification. I also PERSONALIZED and put the RSA public sign key to the SSD to verify the signed applet.

When I try to load a signed CAP file into it, I need to first authenticate myself to Issuer Security Domain (ISD) and load and install my applet into the ISD, then move it to the SSD. It is also possible to remove the applet from the SSD using ISD keys and it's a great concern to the security.

These are the ISD and the SSD package on the card:

ISD: A000000151000000 (OP_READY)
     Parent:  A000000151000000
     From:    A0000001515350
     Privs:   SecurityDomain, CardLock, CardTerminate, CardReset, CVMManagement, TrustedPath, AuthorizedManagement, TokenVerification, GlobalDelete, GlobalLock, GlobalRegistry, FinalApplication, ReceiptGeneration

PKG: A0000001515350 (LOADED)
     Parent:  A000000151000000
     Version: -1.-1
     Applet:  A000000151535041

I also want to know correct privileges needed for the SSD to be able to load a signed CAP file directly to it, knowing the SSD authentication keys, independent from the ISD.

Appendix 1:

I tried to install an SSD with Authorized Management privilege using GlobalPlatform Pro as:

> gp -domain A000000151535041 -privs AuthorizedManagement

Warning: no keys given, using default test key 404142434445464748494A4B4C4D4E4F
Note: using default AID-s for SSD instantiation: A000000151535041 from A0000001515350
INSTALL [for install and make selectable] failed: 0x6A80 (Wrong data/incorrect values in data)

I think that means my card does not support Authorized Management privilege.

Then I tried to give the SSD Delegated Management privilege:

> gp -domain A000000151535041 -privs DelegatedManagement

Warning: no keys given, using default test key 404142434445464748494A4B4C4D4E4F
Note: using default AID-s for SSD instantiation: A000000151535041 from A0000001515350

and this installs the SSD correctly:

> gp -l

Warning: no keys given, using default test key 404142434445464748494A4B4C4D4E4F
ISD: A000000151000000 (OP_READY)
     Parent:  A000000151000000
     From:    A0000001515350
     Privs:   SecurityDomain, CardLock, CardTerminate, CardReset, CVMManagement, TrustedPath, AuthorizedManagement, TokenVerification, GlobalDelete, GlobalLock, GlobalRegistry, FinalApplication, ReceiptGeneration

DOM: A000000151535041 (SELECTABLE)
     Parent:  A000000151000000
     From:    A0000001515350
     Privs:   SecurityDomain, DelegatedManagement, TrustedPath

PKG: A0000001515350 (LOADED)
     Parent:  A000000151000000
     Version: -1.-1
     Applet:  A000000151535041

PKG: A00000016443446F634C697465 (LOADED)
     Parent:  A000000151000000
     Version: 1.0
     Applet:  A00000016443446F634C69746501

PKG: A0000000620204 (LOADED)
     Parent:  A000000151000000
     Version: 1.0

PKG: A0000000620202 (LOADED)
     Parent:  A000000151000000
     Version: 1.3

Next, I personalize the new domain by changing the keys:

> gp -sdaid A000000151535041 --lock BA0DDF2FF5A14AEC07A696D21731AE22

Warning: no keys given, using default test key 404142434445464748494A4B4C4D4E4F
[WARN] GPSession - No key template on card but trying to replace. Implying add
Card locked with: BA0DDF2FF5A14AEC07A696D21731AE22
Write this down, DO NOT FORGET/LOSE IT!

and the domain life cycle goes to PERSONALIZED state:

> gp -l

Warning: no keys given, using default test key 404142434445464748494A4B4C4D4E4F
ISD: A000000151000000 (OP_READY)
     Parent:  A000000151000000
     From:    A0000001515350
     Privs:   SecurityDomain, CardLock, CardTerminate, CardReset, CVMManagement, TrustedPath, AuthorizedManagement, TokenVerification, GlobalDelete, GlobalLock, GlobalRegistry, FinalApplication, ReceiptGeneration

DOM: A000000151535041 (PERSONALIZED)
     Parent:  A000000151000000
     From:    A0000001515350
     Privs:   SecurityDomain, DelegatedManagement, TrustedPath

PKG: A0000001515350 (LOADED)
     Parent:  A000000151000000
     Version: -1.-1
     Applet:  A000000151535041

PKG: A00000016443446F634C697465 (LOADED)
     Parent:  A000000151000000
     Version: 1.0
     Applet:  A00000016443446F634C69746501

PKG: A0000000620204 (LOADED)
     Parent:  A000000151000000
     Version: 1.0

PKG: A0000000620202 (LOADED)
     Parent:  A000000151000000
     Version: 1.3

but when I try to put the public RSA sign key I get an error:

> gp -sdaid A000000151535041 -key BA0DDF2FF5A14AEC07A696D21731AE22 -new-keyver 0x73 --put-key rsaPublicKey.pem

PUT KEY failed: 0x6A81 (Function not supported e.g. card Life Cycle State is CARD_LOCKED)

Appendix 2:

As suggested, I tried to PUT KEY for token verification key as 0x70 version. First I created an SSD:

> gp -domain A000000151535041 -privs DelegatedManagement

Warning: no keys given, using default test key 404142434445464748494A4B4C4D4E4F
Note: using default AID-s for SSD instantiation: A000000151535041 from A0000001515350

and personalize the domain:

> gp -sdaid A000000151535041 --lock BA0DDF2FF5A14AEC07A696D21731AE22

Warning: no keys given, using default test key 404142434445464748494A4B4C4D4E4F
[WARN] GPSession - No key template on card but trying to replace. Implying add
Card locked with: BA0DDF2FF5A14AEC07A696D21731AE22
Write this down, DO NOT FORGET/LOSE IT!

But I have no idea why I cannot put verification key! According to my previous tests, SSDs with DAP Verification privilege accept verification keys with 0x73 version but not 0x70 version. In contrast, SSDs with Delegated Management do not accept keys with both 0x73 and 0x70 versions!

> gp -sdaid A000000151535041 -key BA0DDF2FF5A14AEC07A696D21731AE22 -new-keyver 0x70 --put-key rsaPublicKey.pem

PUT KEY failed: 0x6A81 (Function not supported e.g. card Life Cycle State is CARD_LOCKED)

I also checked Card Capability Information for my card (NXP J3R180 SecID):

<< 80 CA 00 67 00
>> 67 24 A0 09 80 01 02 81 04 15 35 55 75 81 03 E5 BE C0 82 03 1E 03 00 83 01 02 84 01 02 85 01 7B 86 01 0C 87 01 7B 90 00

that means the card supports Delegated Management but not Authorized Management.


Solution

  • There are two ways a SSD will be able to load and instantiate an application, without needing to authenticate to the ISD first:

    DM and AM are set when instantiating the SSD, in the 'privileges' bitmap. You can read about them in the GlobalPlatform Card Specification.

    Not all Secure Elements support DM or AM: you'll have to check the chip manufacturer's documentation.