The interface is a bit easier to use if you use the option to exploit IN objects, as buffers, rather than encapsulate hashing and signature value parameters within the APDUs.
??? Don't get the picture.
I have no problems to use it, I only wanted to mention, that the specification is incorrect(?).
If the answer is to my second mail: MSCComputeCrypt() ... then the problem is, that the application programmer wants to use the API and should not need any knowledge about how it works. It must be transparent. How the implementation works is internal.
The problem with IN objects is, that there is always an additional write cycle. If everything is contained in an APDU, this cycle does not occur. Another thing is, that enough space in the Mem/ObjectManager must be free for this. Further if you sign bigger documents, then the space on a smartcard is never enough, multiple CIPHER_PROCESS instructions are necessary. The hash values could be generated at the PC and then only this result had to be padded and encrypted, but if the aim is to have a trustworthy signature this should be done by the card (the the problem is to get trustworthy clear text from the PC).
Bye, Karsten
Just conceptualize the interface as
Phase 1: init - set IV parms for hash algorithm Phase 2: hash - n rounds of hashing/digesting Phase 3: encrypt current hash
There are other paths through the interface, but the obvious one makes for the easiest programming.
/// NOW TO VERIFY
// delete in object 0xB0 0x52 0x00 0x01 0x04 0xFF 0xFF 0xFF 0xFE;
// 90 00 // verify init (in object) key 2
0xB0 0x36 0x02 0x01 0x05 0x01 0x02 0x01 0x00 0x00;
// 90 00
// create new in object for signing/verifying
0xb0 0x5a 0x00 0x00 0x0e 0xff 0xff 0xff 0xfe 0x00 0x00 0x00 0x0C 0x00 0x00
0x00 0x00 0x00 0x00;
// 90 00
// populate in object for verifying
0xb0 0x54 0x00 0x00 0x0e 0xff 0xff 0xff 0xfe 0x00 0x00 0x00 0x00 0x0A 0x00
0x08 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08;
//90 00
// show the IN object (00 08 .....)
0xb0 0x56 0x00 0x00 0x09 0xff 0xff 0xff 0xfe 0x00 0x00 0x00 0x00 0x0C;
// 90 00
// verify.process key 2 0xB0 0x36 0x02 0x02 0x01 0x02; // 90 00
// delete in object 0xB0 0x52 0x00 0x01 0x04 0xFF 0xFF 0xFF 0xFE;
// 90 00
// create new in object for 768bit signature passing 0xb0 0x5a 0x00 0x00 0x0e 0xff 0xff 0xff 0xfe 0x00 0x00 0x00 0x64 0x00 0x00 0x00 0x00 0x00 0x00; // 90 00
// create new in object for 2048bit signature passing 0xb0 0x5a 0x00 0x00 0x0e 0xff 0xff 0xff 0xfe 0x00 0x00 0x01 0x04 0x00 0x00 0x00 0x00 0x00 0x00; // 90 00
// --- wait for muscleTool write of IN value (sig bytes)
0x00 0x00 0x00 0x00 0x00;
//90 00
// show the IN object (00 08 .....)
0xb0 0x56 0x00 0x00 0x09 0xff 0xff 0xff 0xfe 0x00 0x00 0x00 0x00 0x64;
// 90 00
// verify.finalize key 2 0xB0 0x36 0x02 0x03 0x01 0x02;
// --- END 0x00 0x00 0x00 0x00; //
-----Original Message----- From: [EMAIL PROTECTED] [mailto:muscle- [EMAIL PROTECTED] On Behalf Of Karsten Ohme Sent: Sunday, April 24, 2005 2:56 PM To: MUSCLE Subject: [Muscle] CardEdge specification ComputeCrypt
Hello,
If direction is DIR_VERIFY, then the CIPHER_FINAL block must contain the last input data and the signature to verify.
I think the specification must be updated like this:
- - - - - - - - - - - - - - - - - - - - - -
Extended Data when Operation is CIPHER_FINAL and direction is not DIR_VERIFY: Byte Data Location DataChunk Input Data // If Location == APDU
When operation is CIPHER_FINAL and direction is DIR_VERIFY, last data chunk must be followed by the signature data to be verified.
Extended Data when Operation is CIPHER_FINAL and direction is DIR_VERIFY: Byte Data Location DataChunk Input Data // If Location == APDU DataChunk Signature Data // If Location == APDU
- - - - - - - - - - - - - - - - - - - - - -
Bye, Karsten _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
