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.
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
