Crypto iButton FIPS 140-1 Non-Proprietary Cryptographic Module Security Policy Level 3 Validation 1 Introduction 1.1 Purpose 1.2 For more information 1.3 Terminology 2 The DS1954B Crypto iButton 2.1 The iButton Cryptographic Module 2.2 Physical Security 2.3 DS1954B Firmware Capabilities 2.4 Roles & Services 2.5 Key Management 3 Crypto iButton FIPS Mode 3.1 FIPS Restrictions 3.2 FIPS Configuration 3.3 Operation in FIPS mode 3.4 Factory Configuration Reference |
DS1954B Crypto iButtonFIPS 140-1 Non-Proprietary
|
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 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 zeorize an iButton, create new containers of User Objects and Scripts (Transaction Groups), 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.
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
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.
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:
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 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).
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
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) -} SHAInput =$11 {+ S$FF -} {Auto Objects} Output =$A0 Temp =$A2 Functions: SHA1 =$01End of document.
______________________________
¹ "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
Updated 2000/05/31 Problems or comments? Please e-mail webmaster@dalsemi.com. |
Copyright © 1998 - 1999 Dallas Semiconductor Corp. |