See below, for those interested in designing DeeleteKey into the musclecard cardedge, for either session or long-term objects.
----- Original Message ----- From: "Peter Williams" <[EMAIL PROTECTED]>
To: "MUSCLE" <[EMAIL PROTECTED]>
Sent: Monday, December 13, 2004 8:30 AM
Subject: Re: JCOP USB Token (was Re: [Muscle] Cheap Muscle?)
http://www.bsi.bund.de/zertifiz/zert/reporte/0188b.pdf
Lets consider the security of the Gemplus card, given the consumer-oriented evidence that the company has released for the public to use. Lets assume (probably wrongly) that the ICCs we can obtain actually comply with the disclosures precisely (with masknumbers and firmware revisions, etc.), and the security controller came from the same batch and packaging line as those supplied to the US CVMP and BSI evaluators.
First, the ToE is declared to the BSI as everything EXCEPT (a) the controller (separately evaluated) and (b) the interaction of the TOE with the controller. However, a small note reminds readers that a physical enviornment is assumed (presambly to be disclosed and tested in the FIPS 140-2 process). It discloses that certain tampering detection is contingent on the correct interaction of the ToE with the controller, in that environment. It notes - "The TOE uses information provided by the micro-controller to detect attacks."
Second, the Toe contributes to the application in providing for "Confidentiality of the platform's cryptographic keys, PIN, ES.". We need to find out how confidentiality was defined. It usually means a communciation security service in CC, not an information-level service. We know that "The environment shall ensure that it is not possible to get the D.KEY and theD.GLOBAL_PIN/D.PIN from the Card issuer, the administrator and the End user."
Third "The TOE is an appropriate Embedded Software to implement the Card issuer's policy in order to provide a JCP which can load, install, run and delete Java Card applications with different security levels." We need to discover whether delete an application also implies deleting the instantiated data values. But, at least there is a specific claim of deletion, at a given security level, in compliance with an external policy mandate. We do know that the "D.JAVA_OBJECT" is differentiated from the applet's loaded/linked code: the SEFs may distinguish between the applet deletion and security objectives for the java-object.
Fourth, keys are denominated (D.TSF_KEY) and Application cryptographic (D.USER_KEY). Its not clear whether muscle keys would be a D.USER_KEY asset, and/or whether keys for non-cardmanager security domains are TSF or USER. We can note that hashing alg IVs are not D-USER-KEY, interestingly.
Fifth: crypto keys D.KEY exist in both XRAM and EEPROM, from which both will need to be destroyed and/or deleted.
Sixth: the threat set is modelled in the software boundary model. Given the toe is an embedded firmware module, this is ok. IT dumps the non software SEFs onto the controllers evaluation. Given the ToE's reliance on a physical environment assumption, the threat model is insufficient however. It needs a threat to justify the SEF it will presuambly later disclose to enable the TOE to self-detect tampering of its channel to the controller.
Seventh: The assumption A.CERTIFIED_CHIP is rather vague. If its rsponsible for enforcing the GP state transitions, then this ought to be indicated clearly. We know its responsible for some state transitions - but these could be internal to the chip itself, for its own secure manufacture. Or they could be a combined chip/GP phased manufacturing process (probably).
Eighth: OT.INFO_PROTECTIO "The TOE shall ensure that D.BUFFERS does not hold any usable information of the previous D.APPLET to the current D.APPLET." This says nothing about other current access to the former applets resources that are not in D.BUFFERs. D.buffers for EEPROM is disclosed as the transaction buffer, not long term store. A worrying objective. keys may not be D.Buffer class assets. Similarly, we know that S.CIPHER is the controlling subject for key objects, not the TOE user. This suggests TPM style design and thinking...with normal TPM key release techniques.
Ninth: S.OFFCARD: A human or a process acting on his behalf being located outside the Smart Card IC. I think this means outside the ICC, rather than the controller. Clearly, an compromising process within the module is not addressed in the disclosed threat model
Ten : "FCS_CKM.4.1. The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method (Java Card API) that meets the following standards". OK. so after all that modelling, we dont know a critcal issue and its not disclosed. Kind of useless! Deletion is defined by SUN/implementor of the JCE method. We dont know what it is, or what its relation is to the controllers TOE. The embedded software TOE doesnt say I need to refer to the SUN protection profile, but this may be the next step.
Lets see what information we get from the CVMP evaluation:
http://csrc.nist.gov/cryptval/140-1/140sp/140sp431.pdf
1. "The Gemcpresso Pro R3 E64 PK - FIPS Micro-Module restricts all information flow and physical accesspoints to its physical and logical interfaces that define all entry and exit points to and from the module." This definition of a module clearly requires that its the combination of the Embedded software, the infineon controller, and the SUN Micro assurances (currently unknown set of disclosures). Perhaps swap Sun Micro assurance for the implementor of the JCRE, which may have been GemPlus, or BlueZ, who knows! We'll track down the public disclosures later, if they exist.
2. There is a verified claim that "No code modifying the behavior of the cryptographic module operating system can be added after its manufacturing process." it doesnt say that protection agaisnt other forms of enviornmental influence were validated, note: it only notes code-based influences. Worrying.
3. Really big disclosure (in bold) Application security domains and applet key management are out of the scope of this security policy. I think this means that secure messaging to a non-card manager security domain, or to GP functions in the applet, has not been evaluated. Worrying.
4. "An applet that owns a key is responsible for not sharing it" this is confusing. Above, it said the S.Cipher owns all keys. Surely , its the S.Cipher suibject that must ensure xram and eeprom transaction bufffers are cleared, not the applet. perhaps the term "sharing" means something else, as in SIOs. How an applet is supposed to clear the long-term store of a key, Im not sure. Again, "sharing" may have a technical meaning. in terms of the access control policy, who is the subject who owns adn access key!? user/admin proxy, or S.Cipher?
5. "The cryptographic module provides applets with the capability to set all plaintext cryptographic keys and other unprotected critical security parameters within the module to zero. This also can be done by setting the Card Manager state to OP_Terminated." Setting to zero does not mean delete. I can set my hard disk data to zero; the information is still retrievable. Worrying that the policy discloses key zeroization features. Makes it hard to map the policy evaluation onto the destruction SEFs adn the claims re JavaCard API. _______________________________________________
Muscle mailing list
[EMAIL PROTECTED]
http://lists.drizzle.com/mailman/listinfo/muscle
