AN156
22 of 23
3.4 Validating the User’s Certificate
Validating a certificate from a user token looks a lot like the earlier section on initializing the data. The
steps for signing the data are very similar, but the coprocessor-generated signature is merely matched
against the existing signature, rather than being read into the certificate. Also, since the entire certificate
is merely stored on a file in any user token, the process for validating the certificate is identical across all
tokens. When using an unsigned certificate, this step may only consist of checking the user’s account
balance to make sure it makes sense in the system (i.e. it isn’t negative or it isn’t a trillion dollars).
Validating Transaction Data with SHADEBIT.C Module Figure 42
For signed transaction data, the signature of the certificate must be verified with the coprocessor. As a
nice initial check, the validity of the account balance information can be verified first. This can provide a
quick check to avoid verifying the signature of the account information if it’s unnecessary.
Validating the Account Balance Information Figure 43
The verification of the signature looks very similar to how the signature was created in the first place. The
CRC16 is cleared out (set to zero) and the data signature, after being saved in a buffer, is cleared out and
replaced with the system’s initial signature. Since the new signature will not be written back to the part
and the current signature is being verified against the current value of the write cycle counter, the write
cycle counter is not incremented this time for producing the data signature. The entire process is shown in
Figure 44.
Note that, rather than reading the signature back and matching the signature bytes in software, the
coprocessor’s Match Scratchpad command is used. Since this command only transmits 20 bytes of MAC
information to the coprocessor, rather than reading 32 bytes of scratchpad information from the
coprocessor, this technique is slightly faster. When building a fast, responsive debit application, all non-
essential reads/writes will have to be optimized in this manner. In addition, making sure that the correct
MAC isn’t transmitted from the coprocessor gives an invalid user token no opportunity to grab the right
MAC. This will leave the application less open to holes where the user can take advantage of system
“retries.” For example, if the system was designed to retry the user challenge operation if interrupted, but
eventually repeated a 3-byte random challenge, the user could have stored the appropriate signature.
/* verify the user’s account balance is ‘legal’ */
int balance = (user.accountFile.file.balance[26]&0x0ff);
balance = (balance << 8) | (user.accountFile.file.balance[25]&0x0ff);
balance = (balance << 8) | (user.accountFile.file.balance[24]&0x0ff);
/* MAX_BALANCE, MIN_BALANCE are constant integers */
if( balance>MAX_BALANCE )
printf(“Too Much Money!”);
else if( balance<MIN_BALANCE )
printf(“Not enough money to perform transaction!”);
/* Verify user tokens data, including verifying the data signature */
VerifyData(&copr, &user);
AN156
23 of 23
Validating the Certificate Signature Figure 44
3.5 Updating the User’s Certificate
Updating the user’s certificate is only necessary when using dynamic data. If, for example, the data stored
in the certificate were simply an identification number, there wouldn’t be any need for an update.
Authenticating the user token would ensure that it wasn’t copied from one token to another and validating
the certificate would ensure that it wasn’t tampered with. When using dynamic data, as in the example of
the account balance, it will be necessary to update the certificate information, restore the initial signature,
clear out the CRC16, and resign the data. The breakdown of these steps (with the exception of the
updated data) is identical to those presented in section 2.1. Figure 45 shows the function for updating (and
re-signing if necessary) the transaction data.
Debiting and Updating the User’s Certificate Figure 45
int signAddr = copr.signPageNumber<<5; // physical address of signing page
int wcc = user.writeCycleCounter;
uchar scratchpad[32];
/* save the data signature */
uchar dataSignature[20];
memcpy(dataSignature, user.accountFile.file.signature, 20);
/* clear out the old signature and CRC 16 */
memcpy(user.accountFile.file.signature, copr.initSignature, 20);
user.accountFile.file.crc16[0] = 0x00;
user.accountFile.file.crc16[1] = 0x00;
/* assign the wcc to coprocessor’s “signing” scratchpad (DS1961S wcc=0xFFFFFFFF) */
scratchpad[8] = (wcc&0x0ff);
scratchpad[9] = ((wcc>>=8)&0x0ff);
scratchpad[10] = ((wcc>>=8)&0x0ff);
scratchpad[11] = ((wcc>>=8)&0x0ff);
/* setup the rest of the “signing” scratchpad */
scratchpad[12] = user.accountPageNum;
memcpy(&scratchpad[13], user.devAN, 7);
memcpy(&scratchpad[20], copr.signChlg, 3);
owSerialNum(copr.portnum, copr.devAN, FALSE);
/* write the user’s account page to the coprocessor */
WriteDataPageSHA18(copr.portnum, copr.signPageNumber, user.accountFile.raw, FALSE);
/* write the signing scratchpad */
WriteScratchpadSHA18(copr.portnum, signAddr, scratchpad, 0, 0, TRUE);
/* create the signature */
SHAFunction18(copr.portnum, SHA_SIGN_DATA_PAGE, signAddr, TRUE);
/* match the signature generated by the coprocessor with the user token’s MAC */
if(MatchScratchpadSHA18(copr.portnum, dataSignature, TRUE) )
printf(“Certificate verification Successful!”);
/* Update user token after subtracting 50 cents, with a signed certificate.
* verify that the user token was updated with another read authenticated page. */
ExecuteTransaction(copr, user, 50, TRUE);

DS1963S-F5+

Mfr. #:
Manufacturer:
Maxim Integrated
Description:
iButtons & Accessories SHA iButton
Lifecycle:
New from this manufacturer.
Delivery:
DHL FedEx Ups TNT EMS
Payment:
T/T Paypal Visa MoneyGram Western Union

Products related to this Datasheet