Pitney Bowes iButton Postal Security Device (PSD) Hardware Version: DS1955B PB0 ­1.00c FIPS 140-2 Non-Proprietary Security Policy Level 3 Validation Version 1.07 April 29, 2004 © Copyright 2004 Pitney Bowes (Maxim/Dallas) Page 1 of 21 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. . Table of Contents INTRODUCTION .............................................................................................................3 PURPOSE .......................................................................................................................3 REFERENCES ..................................................................................................................3 DOCUMENT ORGANIZATION ..............................................................................................3 DS1955B PB0 PSD POSTAL SECURITY DEVICE IBUTTON .......................................5 OVERVIEW ......................................................................................................................5 MODULE INTERFACES ......................................................................................................5 Input and Output........................................................................................................6 ROLES AND SERVICES .....................................................................................................6 Crypto Officer Role ....................................................................................................7 Provider Role.............................................................................................................8 User Role...................................................................................................................9 Un-Authenticated Services ......................................................................................10 Authentication Mechanisms.....................................................................................11 PHYSICAL SECURITY .....................................................................................................12 CRYPTOGRAPHIC KEY MANAGEMENT ..............................................................................13 Key Entry and Output ..............................................................................................14 Key Generation........................................................................................................14 Key Access..............................................................................................................15 Key Zeroization........................................................................................................15 SELF-TESTS .................................................................................................................16 DESIGN ASSURANCE .....................................................................................................17 MITIGATION OF OTHER ATTACKS ....................................................................................17 FIPS 140-2 OPERATION OF THE PSD IBUTTON .......................................................18 CRYPTO-OFFICER GUIDANCE .........................................................................................18 Initialization..............................................................................................................18 Distribution...............................................................................................................18 USER GUIDANCE ...........................................................................................................18 Initialization..............................................................................................................19 Zeroization...............................................................................................................19 SECURE OPERATION .................................................................................................20 INITIAL SETUP ...............................................................................................................20 ACRONYMS..................................................................................................................21 © Copyright 2004 Pitney Bowes - Maxim/Dallas Semiconductor Page 2 of 21 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Introduction Purpose This is a non-proprietary Cryptographic Module Security Policy for the Pitney Bowes iButton Postal Security Device (PSD) hardware version DS1955B PB0 ­ 1.00c. This security policy describes how the DS1955B PB0 PSD iButton meets the security requirements of FIPS 140-2 as a multiple-chip standalone module. This policy was prepared as part of the Level 3 (with Environmental Failure Testing) FIPS 140-2 validation of the module. FIPS 140-2 (Federal Information Processing Standards Publication 140-2 -- Security Requirements for Cryptographic Modules) details the U.S. Government requirements for cryptographic modules. More information about the FIPS 140-2 standard and validation program is available on the NIST website at http://csrc.nist.gov/cryptval/. The DS1955B PB0 PSD Postal Security Device is referred to throughout this document as the PSD, PSD iButton, and the module. References This document deals only with operations and capabilities of the module in the technical terms of a FIPS 140-2 cryptographic module security policy. More information is available on the module from the following sources: · The Pitney Bowes website http://www.pb.com/cgi- bin/pb.dll/home/index.jsp contains information on the full line of products from Pitney Bowes. · The NIST Validated Modules website (http://csrc.ncsl.nist.gov/cryptval/) contains contact information for answers to technical or sales-related questions for the module. Document Organization The Security Policy document is one document in a FIPS 140-2 Submission Package. In addition to this document, the Submission Package contains: § Vendor Evidence document § Finite State Machine § Other supporting documentation as additional references With the exception of this Non-Proprietary Security Policy, the FIPS 140-2 Validation Documentation is proprietary to Pitney Bowes and is releasable © Copyright 2004 Pitney Bowes - Maxim/Dallas Semiconductor Page 3 of 21 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. only under appropriate non-disclosure agreements. For access to these documents, please contact Pitney Bowes. © Copyright 2004 Pitney Bowes - Maxim/Dallas Semiconductor Page 4 of 21 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. DS1955B PB0 PSD POSTAL SECURITY DEVICE IBUTTON Overview An iButton is a small hand held device that can be used to carry information. It is durable enough to be able to withstand everyday wear and tear much like the keys on a key chain. They can be dropped, stepped on, and even sent through the washer and dryer without compromising the information inside of the module. A Postal Security Device (PSD) is an iButton that provides the same physical security of the standard iButton, and can also perform cryptographic functions. It also contains a tamper response system that will respond if the PSD is intentionally tampered with and zeroize all of the critical information contained on the module. The DS1955B PB0 PSD is designed to work within the Pitney Bowes Postage Meter System, where it can create and print indicia while keeping track of how much postage the iButton has used and how much it has remaining. The DS1955B PB0 has been hardened to contain only the functionality necessary to perform the postal services, with only one PSD applet locked on to the module. Module Interfaces The cryptographic boundary of the DS1955B PB0 PSD iButton is defined by the stainless steel metal MicroCAN®. There is one physical interface on the PSD iButton that is accessed through the steel lid contact. There are five different logical interfaces on the PSD iButton. The logical interfaces are: Data Input, Data Output, Control Input, Status Output, and Power. © Copyright 2004 Pitney Bowes - Maxim/Dallas Semiconductor Page 5 of 21 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. The logical interfaces are kept logically separate by the 1-WireTM protocol which controls the physical and logical interfaces. The 1-Wire interface is implemented to control how information enters and exits the module. This interface only allows one communication (input/output) at any one given time, which separates the logically interfaces very efficiently. The physical interface is separated into logical interfaces defined by FIPS 140-2, as described in the following table: Module Physical Interface FIPS 140-2 Logical Interface Steel Lid Contact Data Input Interface Steel Lid Contact Data Output Interface Steel Lid Contact Control Input Interface Steel Lid Contact Status Output Interface Steel Lid Contact Power Interface Table 1 ­ FIPS 140-2 Logical Interfaces Input and Output All of the input and output to and from the module is done through the use of Application Protocol Data Units (APDU). The APDU is broken down into these sections: · Class (CLA) · Instruction (INS) · Parameter 1 (P1) · Parameter 2 (P2) · Length of Data Command (Lc) · Command Data (Data [Lc]) The first five define what type of command is being issued. The command data portion holds information that is needed to execute the command. Each service that is provided by the module requires a different APDU to execute the service. Roles and Services The module supports identity-based authentication. There are three roles in the module (as required by FIPS 140-2) that operators may assume: a Crypto Officer Role, a Provider Role and a User Role. © Copyright 2004 Pitney Bowes - Maxim/Dallas Semiconductor Page 6 of 21 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Crypto Officer Role The Crypto Officer role has the ability initialize the module at the factory before having it shipped to the consumer (end-user). Initialization at the factory consists of installing the PSD applet into the ROM of the PSD, running the Power On Self Tests and loading the keys into their specific location in memory in order to prepare the iButton for use by the user. In addition, the Crypto-Officer has access to status functions that return the current status of several of the components of the module. These status functions do not require authentication and are also including in the User Role Services. Descriptions of the services available to the Crypto Officer role are provided in the table below. The Crypto-Officer functionality includes: · Initialization of the module · Running Self Tests on the module · Loading keys onto the module · Generating internal keys (part of the Manufacture Service in the table below) · Distributing the module · Master Erase - Key Zeroization A complete description of the functions available to the Crypto-Officer role can be found in the following table (table 2). Distributing the module from the above list is not included in table 2. The distribution of the module is performed by the crypto-officer by shipping the part to the provider or user role. In table 2, the input and output only depict the data part of the APDU. The first five sections defining which command is being issued is implied. In addition to the APDU, every operation also returns a status output indicating the status of the operation. If the operation completed successfully, the status output reflects this. If the operation is not completed successfully, the output reflects this as well. Role Service Description Input Output Crypto- Get Speed Returns the approximate None Approximate Officer speed of the processor and speeds of the co- co-processor in 1000's of processor and the Hz. CPU Crypto- Initialize Writes the Module's serial Initialize Input Data None Officer number to memory, resets and the Provider the ascending and Public Key descending registers to 0 and loads the Provider Public Key onto the module © Copyright 2004 Pitney Bowes - Maxim/Dallas Semiconductor Page 7 of 21 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Role Service Description Input Output Crypto- Manufacture Loads the secret key that is Encrypted Secret None Officer shared between Pitney Key Bowes and Maxim/Dallas onto the module Crypto- Run Algorithm Gives access to the Dependant upon Dependant upon Officer Cryptographic Algorithms the algorithm being the algorithm being for FIPS Validation executed executed Crypto- Transport Executes the Self Tests Encrypted Random None Officer Unlock and authenticates the Variable Crypto-Officer to the Module Crypto- Master Erase Erases all information from Master Erase Data None Officer the module, and transitions to the Transport PSD State. Table 2 ­ Crypto-Officer Services, Descriptions, Inputs, and Outputs Provider Role The Provider role can perform status checks, load postal configuration data, and generate key pairs. Service descriptions and inputs/outputs are listed in the table below. The Provider functionality includes: · Loading Postal Configuration Data · Authorizing the module to the host · Generating Keys · Master Erase ­ Key Zeroization A complete description of the Provider role services can be found in the following table. In this table, the input and output only depict the data part of the APDU. The first five sections defining which command is being issued is implied. In addition to the APDU, every operation also returns a status output indicating the status of the operation. If the operation completed successfully, the status output reflects this. If the operation is not completed successfully, the status output reflects this as well. Role Service Description Input Output Provider Load Secret Replace the current secret Secret Key Data None Key exchange key, provide a Structure Keypad Refill Key, or keys specific to the French market © Copyright 2004 Pitney Bowes - Maxim/Dallas Semiconductor Page 8 of 21 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Role Service Description Input Output Provider Generate Keys Generates a DSA Key pair Generate PSD Key PSD Public Key Data Data Structure Provider Load Postal Loads important module Postal Configuration None Configuration specific postal information Data to the module Provider Authorize Authorizes the module to PSD Certificate None the host Data Provider Process PVD Accepts a Postage Value Response Message PB Data Center Message Download Message from Status the host and increments the Descending register accordingly Provider Process PVR Accepts the Postage Value Response Message PB Data Center Message Refund message from the Status host and adjusts the registers accordingly Provider Process Audit Resets the Watchdog Audit Response None Response Timer by giving the PSD a Message valid response from the Provider Provider Verify Hash Verifies a hash signature VerifyHashSignature None Signature Structure Provider Master Erase Erases all information from Master Erase Data None the module, and transitions to the Transport PSD State. Table 3 - Provider Services, Descriptions, Inputs, and Outputs User Role User Role The User role can perform status checks, basic postal functions, and self tests. Service descriptions and inputs/outputs are listed in the table below. The User functionality includes: · Logging into/out of the module · Creating Indicium · Printing Indicium · Adding/Removing Postage A complete description of the User role services can be found in the following table. In this table, the input and output only depict the data part of the APDU. The first five sections defining which command is being issued is implied. In addition to the APDU, every operation also returns a status output indicating the status of the operation. If the operation completed successfully, the status output reflects this. If the operation is not completed successfully, the status output reflects this as well. © Copyright 2004 Pitney Bowes - Maxim/Dallas Semiconductor Page 9 of 21 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Role Service Description Input Output User Commit Updates the Ascending None Signed Indicium Transaction and Descending registers Data and outputs the signed indicium User Create Creates an Indicium using Postage Value, Date Signed Indicium Indicium the input date of Mailing, and Rate Data Category User Pre Compute Pre computes the R portion None A signed device R of the DSA signature so audit message that the create indicium function can be executed faster User Pre Create Pre-creates the indicium Postage Value, Date None Indicium based on the input values, of Mailing, and Rate and adjusts the precreated Category register values User Generate PVD Makes a request to the Value of Postage Postage Value Request host to download a Requested Download Request Postage Value Message User Generate PVR Generates a Postage None Postage Value Request Value Refund Request Refund Request Message to send to the Message host User Keypad Refill Adds postage to the Refill amount, and None Descending register ASCII Combination Data User Keypad Removes Postage from the ASCII Combination None Withdrawal Descending register Data User User Login Authenticates the User to Hash of Login None the module Challenge and User Password User User Logout Logs the user out, and None None returns the module to the Full Postal State Table 3 ­ User Services, Descriptions, Inputs, and Outputs Un-Authenticated Services The PSD iButton provides several un-authenticated services. These services consist of basic status inquiries that do not require authentication and are available from any state of operation. The Run Self Tests service is also available from any state in the module, and does not require authentication. These services are detailed in the following table. Role Service Description Input Output © Copyright 2004 Pitney Bowes - Maxim/Dallas Semiconductor Page 10 of 21 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Role Service Description Input Output All Roles Get State Returns the state that the None The current state Module is currently in. All Roles Create Device Sends the value of the None Device Audit Audit Msg Ascending and Descending Message registers to the provider All Roles Run Self Tests Runs the Self Tests None None All Roles Get Module Returns the values of the None The values of the Status Ascending and Descending Ascending and registers Descending registers All Roles Get Challenge Returns the most recent None The Value in the Login Challenge Login Challenge Variable All Roles Get PSD Returns the most recent None The Value in the Parameters Login Challenge Login Challenge Variable All Roles Set GMT Sets the Local time offset GMT offset in None Offset from the GMT Time. seconds All Roles Get Firmware Returns the Firmware None Firmware Version Version Version String String All Roles Get Free RAM Returns the number of free None Number of bytes of bytes of RAM free ram All Roles Get RTC Returns the value of the None The number of Real Time Clock seconds since the battery was attached All Roles Get POR Returns the number of None Number of Power Count Power On Resets since the On Resets since battery was attached the battery was attached All Roles Get Random Returns the number of A request for N N bytes or random random bytes requested bytes of random data data All Roles Get Log Data Returns the contents of a Parameter to Contents of the specified log indicate which log to appropriate log return All Roles Get PSD Key Returns the PSD Public None The PSD Public Data Key if the PSD has been Key authorized Authentication Mechanisms Authenticating to the module is done through the use of keys. The Crypto- Officer and User Roles both authenticate through identity based authentication. The types of authentication are listed in the table below. Authentication Strength Roles Type Transport Key The most recent random login challenge is encrypted using the Crypto-Officer Authentication Transport Key, which is a 2-key 3DES Key. The PSD Role Transport Key is 128 bits. There are 2^128 possible © Copyright 2004 Pitney Bowes - Maxim/Dallas Semiconductor Page 11 of 21 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. combinations for the transport key, which makes the strength of the key 1/(2^128). User Password The User Password is 20 bytes long, and it is hashed with a User Role Authentication random challenge that is 8 bytes long. These are both hashed with SHA-1 to create a 20-byte login command used to authenticate the user. Because the password is 64 bits, the strength of this authentication is a 1/(2^64). PSD Certificate The PSD Certificate Data is digitally signed with the provider Provider Role Data key. The module verifies the signature with the provider key Authentication that was loaded into memory during Initialization and either authorizes the module or does not authorize the module. The strength of this key is based on a 1024 bit DSA public key. DSA is an asymmetric key that is based on the discreet logarithm problem which is a difficult mathematical function. Table 3 ­ Estimated Strength of Authentication Mechanisms Physical Security The DS1955B PB0 PSD iButton is a multi-chip standalone cryptographic module. The cryptographic boundary for the module is the steel enclosure that makes up the iButton. The PSD iButton is contained inside a steel case that is strong, with out any doors or hinges to open to access the module. It does not have any ventilation holes that allow an unauthorized user to gain access to the module. The iButton has a tamper evident mechanism that zeroizes all information if an attempt to tamper the module has occurred. The United States Postal Service requires that devices involved with the Information Based Indicia Program must meet the physical requirements for FIPS 140-2 Level 3. In addition to the level 3 requirements, all modules must be tested for EFP/EFT, which is a level 4 requirement for FIPS. The DS1955B PB0 conforms to the USPS standard by undergoing EFT Tests in addition to meeting the requirements for a FIPS 140-2 Level 3 Validation. The module has been tested in the temperature range between -100C and 200C and in the voltage range of -14 Volts to +14 Volts. These tests have been conducted by the testing laboratory. The Module has been tested and meets Federal Communications Commission (FCC) requirements for home use with regards to Electromagnetic Interference (EMI) and Electromagnetic Compatibility (EMC) for home use as defined in subpart A of FCC part 15. The PSD iButton also meets European Community (EC) Directives Conformity. The CE Mark EMC/EMI/ESD testing requirements are specified by Application of Council Directive 89/336/EEC Standard to which Conformity is Declared: · EN 55022 © Copyright 2004 Pitney Bowes - Maxim/Dallas Semiconductor Page 12 of 21 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. · EN 55024 · EN 61000 Cryptographic Key Management The implementations of the FIPS-approved algorithms have the following FIPS algorithm certifications: § SHA-1 (certificate #167) § DES in CBC Mode (certificate #222) § 3DES in CBC Mode (certificate #185) § 3DES MAC (certificate #185 vendor affirmed) § DSA (certificate #90) The module does not provide any non-FIPS approved algorithms. The module supports the following critical security parameters: Key Key Type Generation Storage Use Kpb 2 key Triple- External by External ­ by Derive Transport Key DES (128-bit) manufacturing Pitney Bowes and Dallas Semiconductor PSD 2 key Triple- Internal ­ set at Plaintext in non- Decrypt input data in Transport DES (128-bit) Dallas prior to volatile memory Transport Unlock Key shipment using the function at state 1, Transport Key and encrypt PSD Derivation Secret Exchange Algorithm in the Key in Load Secret Manufacture Key function function at state 0 PSD Secret 2 key Triple- External by User or Plaintext in non- Encrypt/decrypt data Exchange DES (128-bit) Crypto-Officer volatile memory between the PSD Key and the infrastructure Keypad 2 key Triple- External by User or Plaintext in non- Compute CBC-MAC Refill Key DES (128- bit) Crypto-Officer volatile memory for keypad type refill PSD DSA private Internal ­ uses the Plaintext in non- Digital Signature Private Key key (160-bit) RNG as specified volatile memory in FIPS 186-2 Appendix 3, and uses DES as the © Copyright 2004 Pitney Bowes - Maxim/Dallas Semiconductor Page 13 of 21 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. mixing function G PSD Public DSA public Internal ­ derived Plaintext in non- Compare public key Key key (1024-bit) from PSD Private volatile memory in Certificate signed Key by Provider, for operators to verify PSD's signature Provider DSA public External by Plaintext in non- Verify signed Public Key key (1024-bit) Provider volatile memory messages by Provider French K- 2 key Triple- External ­ derived Plaintext in non- Only for PSDs Fab-MA DES (128-bit) from a shared volatile memory configured for the Key secret key and the French market ­ PSD serial number used to encrypt French K-MA Key French K- 2 key Triple- External ­ loaded Plaintext in non- Only for PSDs MA Key DES (128-bit) upon installation at volatile memory configured for the the customer site French market ­ used to compute a CBC-MAC User Password (64- External ­ Created Plaintext in non- Use by the User Password bit) by User volatile memory login process Table 4 ­ Critical Security Parameters Key Entry and Output Keys that are created externally from the module are never transmitted to the module is plaintext. Keys are encrypted and sent through the physical interface and are then decrypted and stored in plaintext in Non-volatile RAM. After a key has been stored on the module, it is never output for any reason. Key Generation There are two types of keys that are generated within the module. These keys are the PSD Transport Key, and the PSD DSA key pair. The PSD Transport Key is derived using the shared secret key Kpb which is shared between Pitney Bowes and Maxim/Dallas Semiconductor. This key is generated before the PSD has been shipped to the user, and only the Crypto-Officer has access to the PSD Transport key. The PSD DSA key pair is generated during the Generate Keys function, which can be executed in both the Crypto-Officer Role and the User Role. To ensure that the key pair functions properly, a pairwise consistency check is performed on any DSA key pair that the module creates before the pair is used. © Copyright 2004 Pitney Bowes - Maxim/Dallas Semiconductor Page 14 of 21 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Key Access This is a chart that shows which CSP's are available to the different roles and what services they are associated with. Role Key Services Type of Associated Access Crypto-Officer Kpb Manufacture Read Only Crypto-Officer PSD Transport Key Transport Unlock Read Only Load Secret Key Crypto-Officer PSD Secret Transport Unlock Read/Write Exchange Key Load Secret Key Master Erase Provider PSD Secret Master Erase Write Only Exchange Key Crypto-Officer Keypad Refill Key Load Secret Key Write Only User Keypad Refill Key Key Pad Refill Read Only Crypto-Officer PSD Private Key Load Secret Key Read/Write Generate Keys Provider PSD Private Key Generate Keys Read/Write Crypto-Officer PSD Public Key Generate Keys Read/Write Provider PSD Public Key Generate Keys Read/Write Authorize Verify Hash Signature Crypto-Officer Provider Public Key Initialize Write Only Load Secret Key Provider Provider Public Key Verify Hash Read Only Signature Master Erase Crypto-Officer French K-Fab-MA Load Secret Key Read Only Key Crypto-Officer French K-MA Key Load Secret Key Read Only User User Password Initialize Read Only User Login Key Zeroization Key zeroization can occur in two different ways. The first is through a master erase function call that can be called from any state after the module has been initialized. The master erase function removes all of the keys and critical security parameters from the module, and all of them must be entered again for the module to return to normal operation. The module must be returned to the Crypto-Officer to be reinitialized. © Copyright 2004 Pitney Bowes - Maxim/Dallas Semiconductor Page 15 of 21 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. The second method of zeroization is from a tamper event. If the module is tampered with, the tamper response system engages and zeroizes all of the information on the module. Once the module has been tampered, it cannot return to normal operation. Self-Tests The module performs the following Power On Self Tests: · CRC32 Firmware Image Tests ­ This test performs a cyclic redundancy check on the firmware image, and if it does not pass, the test fails. · SHA-1 Known Answer Tests ­ This test performs a known answer test on the SHA-1 algorithm implemented by the module. · DES/3DES Known Answer Tests ­ This test performs a known answer test on the DES and 3DES algorithms implemented by the module. · PRNG Known Answer Tests ­ This test performs a known answer test on the PRNG algorithm that is implemented by the module. · DSA Pairwise Consistency Tests ­ This test creates a DSA key pair, and tests the signing and verification processes with a known message. If one of the Power On Self Tests fail, then the module transitions to the Error state. Once in the error state, successfully passing the self-tests is the only way the module can transition back to the normal mode of operation. The module performs the following Conditional Tests: · RNG Tests ­ When a new set of random bytes is created, it is compared to the previous set created. If the two sets match, then the test fails. · DSA Pairwise Consistency Tests If the conditional tests fail, an error is sent to the status output, and the tests are run again until they are completed successfully. Design Assurance Dallas Semiconductor implements ISO-9000 for design insurance. © Copyright 2004 Pitney Bowes - Maxim/Dallas Semiconductor Page 16 of 21 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Mitigation of Other Attacks The DS1955B PB0 PSD iButton is designed to mitigate against side channel attacks. The 1-Wire® interface transmits power and I/O, this complicates both monitor triggering and collection of data. Signal to noise on the single point of entry through the cryptographic boundary, obscures listening, and making reception of critical data signals more difficult. The main processor is running while the coprocessor operates to introduce additional noise during strong source powered operation. This increased operating current may also improve the Signal/Noise ratio. The ROM based PSD application precludes unauthorized operation or plain text attacks. The following patents can provide additional information for mitigating side channel attacks. The patents are available from the United States Patent Office. Patent Name Patent Number Date 4,890,263 Ram with Capability for Rapid Clearing of Data 12/26/89 From Memory by Simultaneously Selecting All Row Lines 5,327,564 Timed Access System for Protecting Data in a 07/05/94 Central Processing Unit 5,812,004 Current Compensated Clock for a Microcircuit 09/22/98 6,064,740 Method and Apparatus for Masking Modulo 05/16/00 Exponentiation Calculations in an Integrated Circuit 6,219,789 Microprocessor with Co-processing 04/17/01 Capabilities for Secure Transactions and Quick Clearing Capabilities 6,330,668 Integrated Circuit Having Hardware Circuitry to 12/11/01 Prevent Electrical or Thermal Stressing of the Silicon Circuitry FIPS 140-2 OPERATION OF THE PSD IBUTTON The DS1955B PB0 PSD Postal Security Device has three roles, the Crypto-Officer Role, Provider Role and the User Role. The PSD is © Copyright 2004 Pitney Bowes - Maxim/Dallas Semiconductor Page 17 of 21 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. powered on only once when the battery is attached during the manufacturing process. The PSD iButton is a FIPS compliant device and is always in a FIPS approved mode of operation. Crypto-Officer Guidance The Crypto-Officer is responsible for the Initialization of the module at the beginning of its life, as well as any re-initializations that may be needed during the life of the module. The Crypto-Officer is also responsible for distributing the module in a secure manner to prevent compromise before the Provider/User obtains the module. The end of the modules life occurs when the lithium battery dies. Initialization The module is manufactured and initialized at the same facility, so the process of the Crypto-Officer obtaining the module from the manufacturing facility is insignificant. When the Crypto-Officer first receives the module, it is powered on and the Power On Self Tests are executed. After the tests have been successfully completed, then the Crypto-Officer authenticates to the module using information that is encrypted with the PSD Transport Key. After the Crypto-Officer has been authenticated, then the module is ready to be initialized. The Crypto-Officer Initializes the PSD by loading keys onto the module to prepare it to be used by users. The Ascending and Descending registers are initialized and the module is prepared to be distributed to the provider/user. Distribution After the PSD has been initialized and is ready to be distributed to providers/users, it is packaged in a secure package. The package shall contain tamper evident labels that indicate if the module has been tampered with before the provider/user receives it. Provider/User Guidance When the provider/user receives the module, they shall ensure that the tamper evident labels are intact, and that there is no evidence that the device has been tampered. If there is any indication that tampering might have occurred, the provider/user shall return the module to the Crypto- Officer. © Copyright 2004 Pitney Bowes - Maxim/Dallas Semiconductor Page 18 of 21 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Initialization After the provider/user determines that the module is safe to use, the provider must initialize the module. This involves loading the postal configuration data, and authorizing the module to the host. The postal configuration data includes the zip code, the maximum and minimum postage, and the vital information about the module that separates the module from others of the same type (e.g. serial number, etc.). Zeroization When the module has reached the end of its functional life cycle the provider shall perform a Master Erase on the module. The Master Erase zeroizes all information on the module so no unauthorized access can occur. After the Master Erase, the provider shall return the module back to the Crypto-Officer. If, for any reason, the module no longer functions properly, the provider/user shall return the module back to the Crypto-Officer. © Copyright 2004 Pitney Bowes - Maxim/Dallas Semiconductor Page 19 of 21 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. SECURE OPERATION The DS1955B PB0 PSD iButton meets Level 3 requirements for FIPS 140-2. The sections below describe how to place and keep the module in FIPS-approved mode of operation. Initial Setup Once the module has been assembled and the firmware applet has been locked onto the modules ROM, the module is in FIPS compliant. The module remains FIPS compliant during the entire life of the module. The iButton provides strong physical protection of the module, and has a tamper response system that will zeroize all information on the module if it is compromised by physical tampering. The module does not contain any openings, covers, doors, or ventilation holes, and does not require tamper evident labels for FIPS mode. © Copyright 2004 Pitney Bowes - Maxim/Dallas Semiconductor Page 20 of 21 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. ACRONYMS ANSI American National Standards Institute CBC Cipher Block Chaining CMVP Cryptographic Module Validation Program CRC Cyclic Redundancy Check CSE Communications Security Establishment CSP Critical Security Parameter DES/3DES Data Encryption Standard/Triple Data Encryption Standard DPA Differential Power Analysis DSA Digital Signature Algorithm EDC Error Detection Code EFP Environmental Failure Protection EFT Environmental Failure Testing EMC Electromagnetic Compatibility EMI Electromagnetic Interference FCC Federal Communication Commission FIPS Federal Information Processing Standard GMT Greenwich Mean Time KAT Known Answer Test LED Light Emitting Diode MAC Message Authentication Code NIST National Institute of Standards and Technology NVLAP National Voluntary Laboratory Accreditation Program POST Power On Self Test PRNG Pseudo Random Number Generator PSD Postal Security Device PVD Postage Value Download PVR Postage Value Refund RAM Random Access Memory RNG Random Number Generator ROM Read Only Memory SHA Secure Hash Algorithm © Copyright 2004 Pitney Bowes - Maxim/Dallas Semiconductor Page 21 of 21 This document may be freely reproduced and distributed whole and intact including this Copyright Notice.