© Copyright 1998 Dallas Semiconductor Corporation. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. 1-Wire and Cryptographic iButton are trademarks of Dallas Semiconductor Corporation. For important information regarding patents and other intellectual property rights, please refer to Dallas Semiconductor data books. DS1954B Crypto iButton™ FIPS 140-1 Non-Proprietary Cryptographic Module Security Policy Level 3 Validation August 16, 1999 2 Table of Contents 1 Introduction................................................................................................................ 3 1.1 Purpose .................................................................................................................. 3 1.2 For more information............................................................................................. 3 1.3 Terminology .......................................................................................................... 3 2 The DS1954B Crypto iButton™ ............................................................................... 4 2.1 The iButton Cryptographic Module....................................................................... 4 2.1.1 Module Interfaces ........................................................................................... 5 2.1.2 Module Components ....................................................................................... 5 2.2 Physical Security.................................................................................................... 5 2.2.1 The Strength of Steel....................................................................................... 6 2.2.2 Goes Down in a Blaze of Zeroization ............................................................. 6 2.2.3 Neither snow nor rain nor heat…................................................................... 6 2.2.4 Fortresses large and microscopic…............................................................... 7 2.3 DS1954B Firmware Capabilities........................................................................... 7 2.4 Roles & Services ................................................................................................... 7 2.4.1 Transaction Groups, Objects and Scripts....................................................... 8 2.4.2 Authentication................................................................................................. 9 2.4.3 Crypto Officer services ................................................................................... 9 2.4.4 User services................................................................................................. 10 2.4.5 Status Functions............................................................................................ 10 2.5 Key Management................................................................................................. 10 3 Crypto iButton™ FIPS Mode ................................................................................. 12 3.1 FIPS Restrictions ................................................................................................. 12 3.2 FIPS Configuration.............................................................................................. 12 3.3 Operation in FIPS mode ...................................................................................... 13 3.4 Factory Configuration Reference......................................................................... 14 3.4.1 FIPS Mode Transaction Group .................................................................... 14 3.4.2 FIPS Mode Symbol File................................................................................ 16 3 1 Introduction 1.1 Purpose This is a non-proprietary Cryptographic Module Security Policy for the Dallas Semiconductor DS1954B Crypto iButton ™ . This policy was prepared as part of FIPS 140-1 certification of the Crypto iButton. FIPS 140-1 (Federal Information Processing Standards Publication 140-1 -- Security Requirements for Cryptographic Modules) gives U.S. Government requirements for cryptographic modules, and defines the Security Policy as: “A precise specification of the security rules under which the cryptographic module must operate, including rules derived from the security requirements of this standard, and the additional security rules imposed by the manufacturer.” The DS1954B provides extraordinary security, meeting all FIPS 140-1 level 3 requirements, and some level 4 requirements. This security policy describes how the Crypto iButton meets these requirements, and how it can be operated in a secure fashion. 1.2 For more information This document describes the operations and capabilities of the DS1954B Crypto iButton™ in the technical terms of a FIPS 140-1 cryptographic module security policy. For more detailed information about the Crypto iButton, please visit the iButton web site at http://www.ibutton.com. The web site contains non-technical descriptions of Dallas iButton products, technical specifications, product offerings, iButton functionality, iButton developer information, and much more. Fore more information about the FIPS 140-1 standard and validation program please visit the NIST web site at http://csrc.nist.gov/cryptval/. For answers to technical or sales related questions please refer to the contacts listed on the iButton web site at http://www.ibutton.com, or the Dallas Semiconductor web site at http://www.dalsemi.com. 1.3 Terminology In this document the Dallas Semiconductor DS1954B Crypto iButton™ is referred to as the DS1954B, Crypto iButton, cryptographic module, or module. The Crypto iButton is also referred to as simply “iButton”, although this term also applies collectively to other iButtons such as the DS1990, DS1994, or DS1920, which cannot perform computations. 4 2 The DS1954B Crypto iButton™ The Crypto iButton provides hardware cryptographic services such as secure private key storage, a high-speed math accelerator for 1024-bit public key cryptography, and secure message digest (hashing). In FIPS 140-1 terminology the Crypto iButton is a “multi-chip standalone cryptographic module”; however, the Crypto iButton actually provides all its services using a single silicon chip packaged in a 16mm stainless steel case. Thus, the iButton can be worn by a person or attached to an object for up-to-date information at the point of use. The steel button is rugged enough to withstand harsh outdoor environments, and is durable enough for a person to wear everyday on a digital accessory like a ring, key fob, wallet, or badge. Figure 1 – The DS1954B Crypto iButton™ is laser–engraved in steel and silicon 2.1 The iButton Cryptographic Module The cryptographic boundary for the iButton is the surrounding steel shell. This surrounding shell is factory-lasered with the module's unique 64-bit registration number as shown in Figure 2. The figure shows a button with registration number "1A1D2516"16, which is engraved on the encased silicon chip. Figure 2 – Crypto iButton Case and Module Boundary 5 The ground side of the iButton may optionally be branded with logo facings. Registration numbers are also lasered into unalterable ROM on the iButtons, which can be read by any application communicating with an iButton. Strict factory controls ensure that registration numbers are globally unique, guaranteeing that no two iButtons ever share a registration number. 2.1.1 Module Interfaces The button uses a single data contact on the front of the steel case to convey the module’s five logical interfaces: data input, data output, control input, status output, and power. These interfaces are logically separated using the 1-Wire™ protocol, which regulates communications and separates reading, writing, and power applied to the module. The 1- Wire protocol utilizes a scratchpad buffer and features atomic, packetized transfers which assures error-free transmission, even with an intermittent connection, in addition to complete separation of input, processing, and output phases. Control commands and data must be input in error checked packets, and data and status are returned only after successful completion of processing. 2.1.2 Module Components The active components of the iButton are shown below, and consist of a lithium cell (for backup power), an energy reservoir (to provide parasitic capacitance power), a quartz timing crystal (for a True Time Clock), and the single DS83C950 cryptographic chip. Figure 3 – Components of the DS1954B Crypto iButton™ 2.2 Physical Security The Crypto iButton boasts an incredible array of physical security safeguards packed into a small coin-sized device. Because the silicon chip is encased in stainless steel, the 6 iButton will stand up to the harsh conditions of daily wear, including dropping it, stepping on it, and inadvertently passing it through the washing machine and dryer. Figure 3 – The Crypto iButton Mounted as a Signet Jewel of a Ring. It can be attached to any personal accessory 2.2.1 The Strength of Steel The tough stainless steel case of the iButton also defines a contiguous perimeter and provides clear visual evidence of tampering. Tamper-signs include mangling and scratching of the data and ground plates and the smooth grommet separation. It is this outer case which satisfies FIPS 140-1 tamper evidence requirements for physical security. In addition, the case meets the FIPS 140-1 level 3 tamper response and level 4 Environmental Failure Protection (EFP) requirements. 2.2.2 Goes Down in a Blaze of Zeroization If an iButton is pried open, a microswitch triggers an active zeroization of the chip’s contents, destroying private keys and other sensitive information. The iButton constantly monitors the switch’s contacts, and any separation of the cryptographic chip from the lithium cell switches the device to on-chip capacitor power to perform a complete zeroization as it’s last powered action. 2.2.3 Neither snow nor rain nor heat…1 Orchestrated attacks to uncover iButton secrets by subjecting the iButton to extreme temperature or voltage conditions will generate a tamper response that results in zeroization. Deliberately exposure to temperatures outside the iButton’s operational range of -20o C to +70o C (-4o F to +158o F) cause temperature monitors to trigger a cold- temp switch or high-temp effects that quickly zeroize to erase the contents of the 1 “Neither snow nor rain nor heat nor gloom of night stays these couriers from the swift completion of their appointed rounds.” -- an inscription on the General Post Office, New York City. (see http://www.usps.gov/history/his8.htm) 7 memory. Voltages above or below maximum operating tolerances are clamped, and if excessive voltage is encountered, the I/O pin is designed to fuse and render the chip inoperable. 2.2.4 Fortresses large and microscopic… In addition to these operation controls, the cryptographic chip is additionally protected. A substrate barricade is metallurgically- and glass epoxy-bonded to the active face of the chip. Attempts to remove the barrier to get to the chip cause a tamper response that results in zeroization. If a sophisticated attacker attempts to micro-probe the chip, they will encounter a shield of sub-micron pitch metal layers fabricated into a serpentine pattern directly on the chip. The chip will detect any break in this shield and immediately zeroize the chip. 2.3 DS1954B Firmware Capabilities The Crypto iButton contains an 8051-compatible microcontroller, a tamper-evident real- time clock, a high-speed modular exponentiation accelerator for large integers up to 1024 bits in length, 32 Kbytes of ROM memory with preprogrammed firmware, 6 Kbytes of non-volatile RAM (NVRAM) for storage of critical data, input and output buffers with the standard iButton 1-Wire “front-end” for sending and receiving data, and control circuitry that enables the microcontroller to be powered up to interpret and act on the data placed in an input buffer, drawing its operating power from the 1-Wire line. The microcontroller, clock, memory, buffers, 1-Wire front-end, modular exponentiation accelerator, and control circuitry are integrated on a single silicon chip and packaged in a stainless steel case using packaging techniques which make it virtually impossible to probe the data in the NVRAM without destroying the data. Most of the NVRAM is available for use to support cryptographic applications such as those mentioned above. The Crypto iButton firmware supports the Secure Hashing Algorithm (SHA-1) and conforms to Federal Information Processing Standard Publication (FIPS PUB) 180-1, Secure Hash Standard (SHS). 2.4 Roles & Services There are two separate roles in the operation of Crypto iButtons: Crypto Officer, and User. The Crypto iButton is intended to be activated by a service provider (Crypto Officer) who procures an iButton and co-issues the device to his own customers. These registered customers (Users) operate the devices as end users under a license agreement. The Crypto Officer loads the Crypto iButton with data to enable it to perform application specific functions. The User issues commands to the Crypto iButton to perform operations programmed by the Crypto Officer. For this reason the Crypto iButton offers functions to support the Crypto Officer in setting up the Crypto iButton for an intended 8 application, and it also offers functions to allow the authorized User to invoke the services offered by the Crypto Officer. 2.4.1 Transaction Groups, Objects and Scripts A Crypto Officer can reserve a block of NVRAM memory to support services by creating a Transaction Group. A Transaction Group is simply a set of Objects that are defined by the Crypto Officer. These Objects include both data Objects (encryption keys, transaction counts, money amounts, date/time stamps, etc.) and Transaction Scripts which specify how to combine the data Objects in useful ways. The Crypto Officer creates a Transaction Group for a set of Users, which is independent of every other Transaction Group. Hence, a Crypto Officer could offer different sets of services in the same Crypto iButton using different Transaction Groups to support multiple functions for a single iButton. The number of independent Transaction Groups that can be supported depends on the number and size of the Objects defined in each Transaction Group. Examples of some of the Objects that can be defined within a Transaction Group are the following: Modulus Money Register Input Data Exponent Clock Offset Output Data Transaction Script Random Salt Destructor Transaction Counter Configuration Data Within each Transaction Group, the Crypto iButton will initially accept certain commands that have an irreversible effect. Once any of these irreversible commands is executed in a Transaction Group, it remains in effect for the life of the Crypto iButton or until the Transaction Group to which it applies is erased from the Crypto iButton. In addition, there are certain commands that have an irreversible effect on the Crypto iButton as a whole, and remain in effect for the life of the Crypto iButton or until a master erase command is issued to erase the entire contents of the Crypto iButton. These commands are essential to give the Crypto Officer the necessary control over the operations that can be performed by the user. Examples of some of the irreversible changes made by a Crypto Officer are: Privatize an Object Lock an Object Lock a Transaction Group Lock the Crypto iButton Since much of the Crypto iButton’s utility centers on its ability to keep a secret, the Privatize command is the most important irreversible command. The fundamental concept implemented by the firmware is that the Crypto Officer can store Transaction Scripts in a Transaction Group to perform only those operations among Objects that he wishes the authorized User to be able to perform. The Crypto Officer can also store and privatize the private key or keys that allow the Crypto iButton to “sign” transactions on behalf of the Crypto Officer, thereby guaranteeing their authenticity. By privatizing and/or locking one or more Objects in the Transaction Group and locking the Transaction Group itself, the Crypto Officer maintains control over what the Crypto iButton is allowed to do on his behalf. After the group is locked the User cannot add new 9 Transaction Scripts to that Transaction Group and is therefore limited to the operations on Objects that can be performed with the Transaction Scripts programmed by the Crypto Officer. 2.4.2 Authentication The Crypto iButton™ provides identification and authentication (I&A) functions for both role-based and identity-based I&A. 2.4.2.1 Identity-Based Authentication The Crypto iButton™ can perform identity-based authentication using challenge-response protocols that use public key encryption or keyed message digest algorithms. Using these protocols, the iButton™ allows users to log in and log out, and provides automatic logout. When operated in the FIPS mode, the Crypto iButton™ employs identity-based authentication using challenge-response protocols with automatic logout. This advanced I&A is described in section 3.3, and may be used in conjunction with the role-based authentication described below. 2.4.2.2 Role-Based Authentication The Crypto iButton™ may optionally use role-based authentication, in addition to or in lieu of identity-based I&A. There is a Crypto Officer personal identification number (PIN) for each iButton, which must be supplied with each and every service request reserved for the Crypto Officer. The Crypto Officer PIN (also called the iButton’s common PIN) can be any value (numeric, alpha, or binary byte values), and is eight bytes in length. Similarly there is a User PIN for each Transaction Group, which must be supplied with every request for User services. There are also non-cryptographic services (related to iButton status) which are available to User and Crypto Officer without supplying an authenticating PIN. 2.4.3 Crypto Officer services A Crypto Officer can exercise the following services with appropriate authentication: SetCommonPIN MasterErase CreateTransactionGroup LockCiB DisableKeySetGeneration These allow the Crypto Officer to completely erase and zeroize an iButton, create new containers of User Objects and Scripts (Transaction Groups), prevent generation of additional keys, and lock the iButton to prevent additional groups from being added or changed. The Crypto Officer may also authenticate and assume a user role in order to set up information within a particular Transaction Group. A complete description of each Crypto iButton command can be found in the Crypto iButton Firmware Reference Manual. 10 2.4.4 User services A User can exercise the following services with appropriate authentication: SetGroupPIN CreateCiBObject SetCiBObjectAttr LockGroup InvokeScript ReadCiBObject WriteCiBObject DeleteGroup ReadTrueTimeClock ChangeGroupName GenerateRSAKeySet GenerateRSAModAndExp GenerateRSAKeySetNP GeneratePrime GenerateRandomExponent These services allow a user to change PINs, create objects and scripts within a Transaction Group (subject to restrictions already set up by the Crypto Officer), create keys, read and write information from Objects, invoke Scripts, and modify Transaction Group characteristics. Changing a group name affects only name the label and not the Transaction Group ID; however, Locking a Transaction Group disables subsequent creation capabilities. A complete description of each Crypto iButton command can be found in the Crypto iButton Firmware Reference Manual. 2.4.5 Status Functions A number of status functions can be used to find the state of the iButton and various configuration information about the iButton. These status functions can be used by both User and Crypto officer without supplying any PIN: ReadGroupName GetGroupID GetCiBConfiguration ReadRealTimeClock CheckGroupCRC ReadRandomBytes ReadFirmwareVersionID ReadFreeRAM GetCiBError TestRNG 2.5 Key Management The Crypto iButton has a unique internal 64-bit registration number which is not a key, is not private, and is also engraved on the outside of the module. The iButton supports creation of RSA key pairs through the User functions GenerateRSAKeySet, GenerateRSAKeySetNP, GenerateRSAModAndExp and GenerateRandomExponent. GenerateRSAKeySet generates a modulus, public exponent, and private exponent suitable for use as an RSA key pair. Modulus and Public exponent are locked (made read-only), and private exponent is privatized (only accessible by transaction scripts). GenerateRSAModAndExp performs the same function as GenerateRSAKeySet, but allows the public exponent to be chosen. GenerateRandomExponent generates a private exponent when modulus and public exponent are already defined 11 Hence, once keys are created the public keys cannot be modified, and only the scripts defined in the Transaction Group can use the private key. The private key can never be read. If the Transaction Group is locked, or the iButton is locked, the scripts cannot be changed. GenerateRSAKeySetNP performs the same function as GenerateRSAKeySet but does not immediately privatize the private exponent. This would allow the newly generated private key to be read from the iButton until the private key Object is privatized. Although some applications may require this functionality, it is not recommended in the absence of strong procedural controls to protect the private key. Keys are destroyed by deleting the Transaction Group that contains them (which destroys all objects within it, calling the master erase command (which destroys all Transaction Groups), or by triggering a tamper response. 12 3 Crypto iButton™ FIPS Mode The Crypto iButton™ provides a rich set of cryptographic functionality in a physically secure package. This versatile module can be configured to function in a wide variety of applications such as an electronic change purse, biometric access token, or postage meter. The iButton™ can also be configured to operate in a FIPS 140-1 compliant mode. When configured and operated in this mode, the Crypto iButton™ provides a FIPS 140-1 level 3 compliant cryptographic module. In all forms of operation, the Crypto iButton™ meets all level 3 and some level 4 FIPS 140-1 physical security requirements using sophisticated hardware security controls. Other areas of FIPS level 3 requirements can only be met if the Crypto iButton™ is configured for and operated in its FIPS mode. 3.1 FIPS Restrictions FIPS 140-1 requires that RSA digital signatures follow the FIPS 186-1 standard. Currently, the Crypto iButton only support RSA digital signatures as specified in PKCS#1. Therefore, the Crypto iButton™ uses only SHA-1 for message digests in the FIPS mode. The Crypto iButton™ provides several methods of identification and authentication to provide role-based or identity-based authentication. In order to meet level 3 FIPS 140-1 requirements the iButton™ must be operated using identity-based authentication. The module is operated as a single-user device with identity-based authentication of the user as described in section 2.4.2.1. The user immediately assumes both Crypto Officer and User roles. The authentication used in the FIPS mode incorporates a challenge-response protocol for login. The protocol ensures that no plaintext authentication data is transmitted over the 1-Wire™ interface. In addition, this authentication does not use RSA encryption, instead utilizing a keyed message digest algorithm incorporating SHA-1. For operation in FIPS mode, no plaintext keys may be exported from the iButton™. Therefore, all keys are privatized and only accessed internally by scripts. 3.2 FIPS Configuration To configure the iButton™ for operation in FIPS mode, the factory performs the following operations: • Perform a Master Erase on the iButton™, removing all previous data. • Initialize the common PIN to a random value known only to the factory. The common PIN is set with both the PIN_TO_CREATE and PIN_TO_ERASE options. • Set a User login password. • Add the User Transaction Group described in section 3.4. • Lock the Transaction Group • Create a final empty Transaction Group 13 • Lock the iButton to lock the final group, disable key generation, and prevent any future changes. • Deliver the FIPS mode iButton™ and User login information. 3.3 Operation in FIPS mode Operation of a Crypto iButton™ in FIPS mode is limited to a subset of the capabilities described in section 2.4. Because the factory initializes the button and does not release the Common PIN for the FIPS mode iButton™, the user cannot exercise any of the services listed in section 2.4.3. In addition, the Transaction Groups and the iButton™ itself are locked, which prevents the User from exercising the following User services. CreateCiBObject SetCiBObjectAttr LockGroup DeleteGroup GenerateRSAKeySet GenerateRSAModAndExp GenerateRSAKeySetNP GeneratePrime GenerateRandomExponent Thus, the User cannot create or delete Transaction Groups. Within existing Transaction Groups, the user cannot create new objects, cannot create new scripts, and cannot create new keys. The User is limited to exercising the status services and the following User services: SetGroupPIN ReadTrueTimeClock ChangeGroupName InvokeScript ReadCiBObject WriteCiBObject The User can read the true time clock on the iButton, change the label attached to the User group, or change the Group PIN from its FIPS mode null default. In addition the user can use WriteCiBObject to write input data to a script (no other objects are writable), or ReadCiBObject to read the random login challenge, time for automatic logout, automatic logout interval, or output data from scripts. The User can also invoke one of the four scripts: Login, Logout, EraseUser, and SHA1Digest. Three of these scripts are considered to be User role services (Login, Logout, and SHA1Digest) and one script is considered to be a Crypto Officer role service (EraseUser). The User must first login to the iButton™ using the Login script. To do this, the user reads the random challenge data. The random challenge is then "Xor"ed with the User login password and the result is hashed using SHA-1 to compute the challenge response. This response is provided to the Login script along with the number of seconds before automatic logout occurs. Once a User has logged in, she may run the SHA1Digest script to hash data, run the Logout script, or await automatic logout. If the User runs the EraseUser script, or 14 provides ten successive invalid login responses, all User data will be erased from the iButton™ and the User deleted. Once a User has been erased, the User can no longer login and the FIPS mode iButton™ must be returned to the factory. 3.4 Factory Configuration Reference All FIPS mode iButtons™ are delivered from the factory tested, operational, and configured. The Transaction Group described below containing the following scripts is loaded into the iButton™ customized with a User login password. The full factory configuration process is described in section 3.2. 3.4.1 FIPS Mode Transaction Group The following transaction group is loaded into each FIPS mode iButton™. It includes four scripts described separately below, two writeable objects for input, and four readable objects for output. Only the Login script is available to the User before successful authentication. The Logout, EraseUser, and SHA1Digest scripts are destructible and are only available after login sets the destructor (LogoutTime) object. {TransactionGroup for FIPS 140-1 Level 3 compliant identity based authentication} TransactionGroup('FIPS Lev3 User1'); Begin Open: LoginInput: InputData; {A writable object for Login data input} SHAInput: InputData; {A writable object for SHA hashing input} Locked: RandomChallenge: Configuration; {Login challenge string that changes every attempt} Timeout: ClockOffset; {How long to delay autologout} LogoutTime: Destructor; {Time when auto Logout occurs} Output: OutputData; {Readable output data} Login: Script; Logout: Script; Destructible; EraseUser: Script; Destructible; SHA1Digest: Script; Destructible; Private: Temp: WorkingRegister; {Protected temporary calculation register} Response: Money; {Calculated response to login challenge} LoginPassword: Configuration; {User Login Password} FailedLoginCount: Counter; {Unsuccessful login count} FailedLoginVal: Money; {Copy of FailedLoginCount for comparisons} ZeroVal: Money; {Literal constant} TenVal: Money; {Literal constant} ZeroOffset: ClockOffset; {Literal constant} NewChallenge: Salt; {New RandomChallenge value} End 3.4.1.1 Login Script: The login script accepts a response to the login from a User (operating in the User role) along with an automatic logout timeout interval. The response must be the SHA-1 hash of the challenge (from the RandomChallenge variable) "Xor"ed with the User login password. The automatic logout timeout interval defines how long the iButton™ remains logged in after the last successful Login or SHA1Digest script is executed. The Login Script counts unsuccessful login attempts and will destroy the User data after 10 successive unsuccessful attempts. The random challenge is changed after every login attempt (whether or not it was successful). 15 Script Login; { LoginInput is a packet that contains two embedded objects. The first object is the response to the login challenge, and the second is the number of seconds for the Crypto iButton to remain logged in (without any script activity). The Login script calculates the correct response to the challenge using a keyed message digest and places it in the Response object. If the input response matches the response generated by the script, the seconds count passed in the packet is added to the current value of the CiB's RTC (real time clock) and the result is placed in the destructor object. If ten login attempts fail, the user is prevented from logging in, and all user information is destroyed. The login challenge is changed after every login attempt. } Begin {Make sure user has not been permanently erased } {When user is erased, FailedLoginVal has reached 10 } If FailedLoginVal = TenVal Then Begin Continue(EraseUser); {Jump to erase user script} Exit(10); {Return error code of 10 to indicate erased user} End {Compute correct response to challenge} Temp := LoginPassword Xor RandomChallenge; Response := SHA1(Temp); {Check computed response against input response} {The input response is the embedded Money object in LoginInput} If Response = LoginInput.Money[1] Then {Login Succeeds} Begin FailedLoginCount := ZeroVal; {Reset unsuccessful login count} FailedLoginVal := ZeroVal; {Reset unsuccessful login value} Timeout := LoginInput.ClockOffset[1]; {Read logout delay from LoginInput} LogoutTime := Timeout; {LogoutTime = Timeout + RTC} {Set logout delay} RandomChallenge := NewChallenge; {Generate new challenge} Exit(0); {Successful login return code is zero} End {Login Fails} LogoutTime := ZeroOffset; {disable login, record last attempt time} FailedLoginVal := FailedLoginCount; {increment failed login counter, store in value} RandomChallenge := NewChallenge; {Generate new challenge} Exit(20); {Failed login return code is twenty} End 3.4.1.2 Logout Script The Logout Script immediately logs out a User without waiting for the automatic logout timer to take effect. Script Logout; { Logout the User from the transaction group before the timeout logs you out automatically. } Begin LogoutTime := ZeroOffset; {logout by setting destructor to current time} End 16 3.4.1.3 SHA-1 Digest Script The SHA-1 Digest Script allows a User (operating in the User role) to hash input data and receive the message digest in response. Performing a hash also resets the automatic logout timer to the timeout value specified by the user at login. Script SHA1Digest; { Perform a SHA1 message digest on an input value. The output is returned in the Output variable. } Begin {SHA-1 hash the input and return it in the Output} Output := SHA1(SHAInput); {reset logout timer because of this activity} LogoutTime := Timeout; {LogoutTime = Timeout + RTC} End 3.4.1.4 Erase User Script The Erase User Script allows a User (operating in the Crypto Officer role) to actively erase his User information. This effectively destroys all critical security parameters stored in a FIPS mode iButton. This script is also effectively run if there are ten successive unsuccessful login attempts. Script EraseUser; { Erase a user's authentication data and prevent that user from logging in ever again. This script is to provide a user a local zeroization function within a single Transaction Group. } Begin LoginPassword := ZeroVal; {Destroy user secret value} RandomChallenge := ZeroVal; {Destroy login challenge value} TimeOut := ZeroVal; {Reset inactivity time value} LogoutTime := ZeroOffset; {Log user out for last time} FailedLoginCount := TenVal; {Never allow user to login again} FailedLoginVal := TenVal; {Never allow user to login again} Exit(10); {Return error code of 10 to indicate erased user} End 3.4.2 FIPS Mode Symbol File Every iButton™ Transaction Group requires a symbol file, which assigns internal identifiers and initial values to all objects. The FIPS mode symbol file sets an initial random value for the RandomChallenge and sets the User login password. LoginInput =$01 {+ S$1C -} RandomChallenge =$02 {+ S$80 I(R$80) -} Timeout =$03 {+ S$04 -} LogoutTime =$04 {+ S$04 I($00) -} Login =$05 Logout =$06 EraseUser =$07 SHA1Digest =$08 LoginPassword =$09 {+ S128 I'Any password can be set here' -} FailedLoginCount =$0A {+ S1 I($00)-} FailedLoginVal =$0B {+ S1 I($00)-} ZeroVal =$0C {+ S1 I($00)-} TenVal =$0D {+ S1 I($0A)-} NewChallenge =$0E {+ S$80 I(R$80) -} Response =$0F {+ S$14 -} ZeroOffset =$10 {+ S$04 I($00) -} 17 SHAInput =$11 {+ S$FF -} {Auto Objects} Output =$A0 Temp =$A2 Functions: SHA1 =$01 End of document.