AN156
3 of 23
is something that isn't important to the specific system, the SHAiButtonUser class could easily be
extended to support 1-Wire memory devices, which would just carry signed account information. Note
that using other memory devices rules out the use of a challenge-response protocol for authenticating the
iButton. There is still a minimal level of security in the user token's 64-bit ROM ID.
2.1 Initializing the Coprocessor
Initializing the coprocessor consists of two important steps: installing the system authentication secret and
installing the system signing secret. An optional third step is to write all of the system configuration data
to the iButton in the form of a file (see AN114). The configuration data doesn’t have to be stored on the
coprocessor iButton, but it’s convenient to keep the system parameters as portable as the coprocessor. As
an alternative, the file can be stored on a disk drive or the parameters can be hardcoded in your
application.
The following blocks of code demonstrate the initialization of the coprocessor. Each block of code is well
commented and the declarations of all variables used are shown. The intent is that the code can be copied
into a project used after just a few edits.
Necessary System Parameters for a SHA Application Figure 2
/* The input data to be used for calculating the master authentication and signing
* secrets. The calculation involves splitting the secret into blocks of 47 bytes
* (32 bytes to the data page, 15 bytes to the scratchpad) and then performing the
* SHA command Compute First Secret, followed by Compute Next Secret for each 47
* byte block after the first. */
yte[] inputAuthSecret, inputSignSecret; // . . . initialize from user input
/* The page to use for the signing secret must be page 8, because secret 0 is the
* only secret that can be used for the SHA command Sign Data Page. For a list of
* SHA commands, and what pages they can be used on, see the DS1963S datasheet. */
int signPageNumber = 8;
/* The authentication secret can be on any page as long as it doesn’t collide with
* the file holding coprocessor configuration information and not secret 0 */
int authPageNumber = 7;
/* The workspace page is the page the coprocessor will use for recreating a user’s
* unique authentication secret and it’s authentication response. */
int wspcPageNumber = 9;
/* The binding information is used to create the “unique” secret for each button.
* bindData is written to the data page of the user token, and bindCode is written
* to the scratchpad. The result of a Compute Next Secret using the system
* authentication secret, the account page number, the rom ID of the user token, the
* bind data, and the bind code becomes the user’s unique authentication secret.
* This is used to initialize a user token and the coprocessor must use the same
* data to recreate the user token’s unique secret. */
yte[] bindData = new byte[32], bindCode = new byte[7]; // . . . user input
/* Initial signature to use when signing the certificate */
yte[] initSignature = new byte[20]; // . . . user input
/* Three byte challenge used when signing the certificate */
yte[] signingChlg = new byte[3]; // . . . one time random calculation or user input
/* Name of the account file (and file extension) to create on user tokens */
yte[] acctFilename = (“DLSM”).getBytes();
int acctFileExt = 102; // extension for “money” files
