Pitney Bowes iButton Postal Security Device (PSD) Hardware Version: MAXQ1959B-F50# Firmware Version: 5.01.01 FIPS 140-2 Non-Proprietary Security Policy Level 3 Validation Document Version 1.0 July 16, 2010 © Copyright 2010 Pitney Bowes (Maxim Integrated Products) Page 1 of 19 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. . Table of Contents INTRODUCTION ............................................................................................................. 3 PURPOSE ....................................................................................................................... 3 REFERENCES ................................................................................................................. 3 MAXQ1959B#F50 PSD POSTAL SECURITY DEVICE IBUTTON ................................. 4 OVERVIEW ..................................................................................................................... 4 MODULE INTERFACES ..................................................................................................... 5 Input and Output........................................................................................................ 5 ROLES AND SERVICES ..................................................................................................... 6 Provider (Crypto-Officer) Role ................................................................................... 6 User Role .................................................................................................................. 7 Un-Authenticated Services ........................................................................................ 8 Authentication Mechanisms ...................................................................................... 9 PHYSICAL SECURITY ..................................................................................................... 10 CRYPTOGRAPHIC KEY MANAGEMENT ............................................................................. 10 Key Entry and Output .............................................................................................. 12 Key Generation ....................................................................................................... 12 Key Access ............................................................................................................. 12 Key Zeroization ....................................................................................................... 13 SELF-TESTS ................................................................................................................. 14 DESIGN ASSURANCE ..................................................................................................... 16 MITIGATION OF OTHER ATTACKS .................................................................................... 16 FIPS 140-2 OPERATION OF THE PSD IBUTTON....................................................... 17 CRYPTO-OFFICER GUIDANCE ........................................................................................ 17 Initialization ............................................................................................................. 17 Zeroization .............................................................................................................. 17 USER GUIDANCE .......................................................................................................... 17 SECURE OPERATION ................................................................................................. 18 FIPS MODE INDICATOR ................................................................................................. 18 ACRONYMS ................................................................................................................. 19 © Copyright 2010 Pitney Bowes - Maxim Integrated Products Page 2 of 19 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 MAXQ1959B-F50#, when loaded with firmware version ­ 5.01.01 (PB5). This security policy describes how the MAXQ1959B-F50# 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 FIPS 140-2 validation of the module (plus Level 4 Environmental Failure Testing). 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 CMVP website at http://csrc.nist.gov/groups/STM/cmvp/. The MAXQ1959B-F50# 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/jsp/Home.do contains information on the full line of products from Pitney Bowes. · The CMVP website (http://csrc.nist.gov/groups/STM/cmvp/) contains a listing of validated modules that includes contact information for answers to technical or sales-related questions for the module. © Copyright 2010 Pitney Bowes - Maxim Integrated Products Page 3 of 19 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. MAXQ1959B#F50 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 MAXQ1959B-F50# 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 MAXQ1959B-F50# has been hardened to contain only the functionality necessary to perform the postal services, with only one PSD application locked on to the module. The MAXQ1959#F50 PSD is manufactured for compliance to the Restriction of Hazardous Substances (ROHS) Act. A # sign is laser branded within the part number to indicate ROHS Compliance. © Copyright 2010 Pitney Bowes - Maxim Integrated Products Page 4 of 19 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Security Requirements Section Level Cryptographic Module Specification 3 Module Ports and Interfaces 3 Roles, Services, and Authentication 3 Finite State Model 3 Physical Security Requirements 3 + EFP Operational Environment N/A Cryptographic Key Management 3 EMI/EMC 3 Self-tests 3 Design Assurance 3 Mitigation of Attacks 3 Table 1 - Cryptographic Module Security Levels Module Interfaces The cryptographic boundary of the MAXQ1959B-F50# 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. The logical interfaces are kept logically separate by the 1-Wire® 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 2 ­ 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) © Copyright 2010 Pitney Bowes - Maxim Integrated Products Page 5 of 19 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. · 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 two roles in the module (as required by FIPS 140-2) that operators may assume: a Provider (crypto-officer) Role and a User Role. Provider (Crypto-Officer) 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 Table 3. 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 USA or Canada market © Copyright 2010 Pitney Bowes - Maxim Integrated Products Page 6 of 19 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 ECDSA Key Generate PSD Key PSD Public Key pair (160-bit) or (192-bit) Data Data Structure Provider Load Postal Loads important module Postal None Configuration specific postal information Configuration 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 Timer Audit Response None Response by giving the PSD a valid Message response from the Provider Provider Verify Hash Verifies a hash signature Verify Hash None Signature Signature Structure Provider Master Erase Erases all information from Master Erase Data None the module, and transitions to the Transport PSD State. Provider Disable PSD Places the PSD in a mode None None in which it cannot perform any Postal functions. Provider Enable PSD Reverts the PSD to a mode None None in which it can carry out its Postal functions. Table 3 - Provider Services, Descriptions, Inputs, and Outputs 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 © Copyright 2010 Pitney Bowes - Maxim Integrated Products Page 7 of 19 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. 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. 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 ECDSA 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 4 ­ 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 © Copyright 2010 Pitney Bowes - Maxim Integrated Products Page 8 of 19 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. 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 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 Outputs the PSD None PSD Parameters Parameters Parameters List Structure List Structure 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 Salt Returns a non- A request for N N bytes salt/nonce cryptographic value used bytes salt/nonce value for salt and nonce values value 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 Table 5 ­ Un-authenticated Services, Descriptions, Inputs, and Outputs Authentication Mechanisms Authenticating to the module is done through either challenge response or by asymmetric signature. The Provider (Crypto-Officer) and User authenticate through identity-based authentication, by demonstrating knowledge of the following keys and CSPs: Provider Role: ECDSA Key Pair (P-192 or P-160) © Copyright 2010 Pitney Bowes - Maxim Integrated Products Page 9 of 19 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. User Role: 8-byte password The types of authentication are listed in the table below. Authentication Strength Roles Type Provider Signature The module uses the Provider Public Key to verify the Provider Role Verification signature on input commands and authenticates the operator based on the signature verification. The smallest supported curve (P-160) for the ECDSA key provides 80-bits of equivalent symmetric strength providing a 1/(2^80) strength of authentication. User Password The User Password is 8 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). Table 6 ­ Estimated Strength of Authentication Mechanisms Physical Security The MAXQ1959B-F50# 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, without 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 response mechanism that zeroizes all information if an attempt to tamper the module has occurred. This is provided as part of the module's mitigation of other attacks. The United States Postal Service requires that devices involved with the Information Based Indicia Program (IBIP) must meet the physical requirements for FIPS 140-2 Level 3. In addition to the level 3 requirements, all modules must be tested EFP, which is a level 4 physical security requirement for FIPS. The MAXQ1959B-F50# conforms to the USPS standard by undergoing EFP Tests in addition to meeting the requirements for a FIPS 140-2 Level 3 Validation. The module is designed to perform zeroization when operated outside the normal temperature range between -50°C and 125°C and in the voltage range of ±4 Volts. These tests have been conducted by the testing laboratory. Cryptographic Key Management The module supports the following FIPS approved algorithms: SHA-1 (Certificate #1177) © Copyright 2010 Pitney Bowes - Maxim Integrated Products Page 10 of 19 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. RNG (Certificate #715) Triple-DES (Certificate #904) Triple-DES MAC (Triple-DES Certificate #904; vendor-affirmed) HMAC (Certificate #746) ECDSA (Certificate #153) ­ In addition to the NIST recommended P-192 curve, the module also supports the P-160 curve. The module also uses the following non-approved algorithms while operating in FIPS mode: Non-deterministic Hardware RNG Non-approved Firmware RNG The module supports the following critical security parameters: Key Key Type Generation Storage Use PSD Secret Two-key Triple- Unique for each Plaintext in non- Decrypt secret keys Exchange Key DES (112-bit) module. External by volatile memory entered into the PSD Crypto-Officer Keypad Refill Two-key Triple- External by User or Plaintext in non- Compute CBC-MAC for Key DES (112-bit) Crypto-Officer volatile memory keypad type refill PSD Private ECDSA key set Internal ­ Uses the Plaintext in non- Digital Signature Key (160-bit) or (192- FIPS 186-2 approved volatile memory bit) ECDSA key generation method PSD Public EDDSA key set Internal ­ Uses the Plaintext in non- Provided to external Key (160-bit) or (192- FIPS 186-2 approved volatile memory operators for verification bit) ECDSA key generation of signature generated method using PSD Private Key Provider ECDSA key set External by Provider Plaintext in non- Verify Provider signed Public Key (160-bit) or (192- volatile memory messages bit) HMAC Secret MAC Key (80-bit) External ­ Provided by Plaintext in non- Calculation of MAC Key user volatile memory values in Canada Indicia User Password (64-bit) External ­ Created Plaintext in non- Used by the User login Password during manufacturing volatile memory process for association with postal meter x-Key Seed FIPS 186-2 RNG Generated internally Plaintext in non- Used as the seed key Key Seed Key (20- using non-approved volatile memory value for the FIPS 186-2 byte) RNG x-Regular RNG k-Key Seed FIPS 186-2 RNG Generated internally Plaintext in non- Used as the seed key Key Seed Key (20- using non-approved volatile memory value for the FIPS 186-2 byte) RNG k-Regular RNG Table 7 ­ Critical Security Parameters © Copyright 2010 Pitney Bowes - Maxim Integrated Products Page 11 of 19 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Key Entry and Output Keys that are created externally from the module are never transmitted to the module in plaintext. Keys are encrypted with the (Two-key [112-bit] Triple-DES) PSD Secret Exchange Key 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 The only key generated within the module is the PSD ECDSA key set. The PSD ECDSA key set is generated during the Generate Keys function, which can be executed in the Provider Role. To ensure that the key pair functions properly, a pairwise consistency check is performed on any ECDSA key set that the module creates before the pair is used. Key Access The following Table shows the type of access that various services have to the CSPs. Services not listed in the Table do not have access to CSPs. Load Secret Key Generate Key Authorize Data Load Postal Config. Process PVD Message Process PVR Message Message Process Audit Verify Hash Signature Disable PSD Enable PSD Master Erase Commit Transaction Create Indicium Pre-Compute R Keypad Refill User Login Get PSD Key Data PSD Secret W/X W Exchange Key Keypad Refill W W X Key PSD Private X W W X X X Key PSD Public R/W X X W R Key Provider X X X X X X X X X X W/X Public Key HMAC Key W X User W X Password x-Key Seed X Key k-Key Seed X Key © Copyright 2010 Pitney Bowes - Maxim Integrated Products Page 12 of 19 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Table 8 ­ Critical Security Parameter Access Table 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 manufacturer to be reinitialized. 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. © Copyright 2010 Pitney Bowes - Maxim Integrated Products Page 13 of 19 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. 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. · HMAC Known Answer Tests ­ This test performs a known answer test on the HMAC SHA-1 algorithm implemented by the module. · Triple-DES Known Answer Tests ­ This test performs a known answer test on the Triple-DES algorithm implemented by the module. · RNG Known Answer Tests ­ This test performs a known answer test on all approved RNG algorithms that are implemented by the module. · ECDSA Sign-Verify Tests ­ This test creates an ECDSA key pair, and tests the signing and verification processes with a known message. If one of the Power-On Self Tests fails, 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: · Continuous RNG Tests for Firmware RNGs ­ This test is performed when a number is generated using any of the Firmware RNGs implemented by the module whether approved or non-approved. · Continuous RNG Test for Hardware RNG - This test is performed when a number is generated using the Hardware RNG implemented by the module · ECDSA Pairwise Consistency Tests If the CRNGT for Firmware RNGs or ECDSA pairwise consistency test fail, an error is sent to the status output, and the module enters the same error state as the power-on self-tests. © Copyright 2010 Pitney Bowes - Maxim Integrated Products Page 14 of 19 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. If the CRNGT for the Hardware RNG fails, the module reports the error and attempts to generate a value again. If this generation fails three times, the module returns the error indicator and enters the same error state as the power-on self-tests. © Copyright 2010 Pitney Bowes - Maxim Integrated Products Page 15 of 19 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Design Assurance Maxim Integrated Products Inc. implements ISO-9000 for design assurance. Mitigation of Other Attacks The MAXQ1959B-F50# 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 makes 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 application storage of the FLASH-based PSD is locked during manufacturing precluding 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 From 12/26/89 Memory by Simultaneously Selecting All Row Lines 5,327,564 Timed Access System for Protecting Data in a Central 07/05/94 Processing Unit 5,812,004 Current Compensated Clock for a Microcircuit 09/22/98 6,064,740 Method and Apparatus for Masking Modulo Exponentiation 05/16/00 Calculations in an Integrated Circuit 6,219,789 Microprocessor with Co-processing Capabilities for Secure 04/17/01 Transactions and Quick Clearing Capabilities 6,330,668 Integrated Circuit Having Hardware Circuitry to Prevent 12/11/01 Electrical or Thermal Stressing of the Silicon Circuitry Table 9 ­ Module Mitigation of Other Attacks Patents Additionally, the iButton provides extra physical protections against attacks beyond those required for Level 3 Physical Security. The iButton has a tamper response mechanism that zeroizes all information if an attempt to tamper the module has occurred. © Copyright 2010 Pitney Bowes - Maxim Integrated Products Page 16 of 19 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. FIPS 140-2 OPERATION OF THE PSD IBUTTON The MAXQ1959B-F50# PSD Postal Security Device has two roles, the Provider (Crypto-Officer) Role and the User Role. The PSD is powered on only once when the battery is attached during the manufacturing process. The module always operates in the FIPS mode of operation. Crypto-Officer Guidance The crypto-officer should inspect the module upon receipt and ensure that there is no evidence of tampering. If there is evidence of potential tamper, then the module should be returned to Pitney Bowes. Initialization After the crypto-officer determines that the module is safe to use, they 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 Pitney Bowes. If, for any reason, the module no longer functions properly, the provider shall return the module back to Pitney Bowes. User Guidance If, for any reason, the module no longer functions properly, the user shall return the module back to Pitney Bowes. © Copyright 2010 Pitney Bowes - Maxim Integrated Products Page 17 of 19 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. SECURE OPERATION The MAXQ1959B-F50# PSD iButton meets Level 3 requirements for FIPS 140-2. The sections below describe how verify that the module is operating in its FIPS-approved mode of operation. FIPS Mode Indicator The module always operates in the FIPS approved mode of operation. An operator can confirm they are running the FIPS validated module by using the Get Firmware Version service to confirm the validated firmware version (5.01.01) is installed. © Copyright 2010 Pitney Bowes - Maxim Integrated Products Page 18 of 19 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. ACRONYMS CBC Cipher Block Chaining CRC Cyclic Redundancy Check CSP Critical Security Parameter ECDSA Elliptic Curve Digital Signature Algorithm EFP Environmental Failure Protection EMC Electromagnetic Compatibility EMI Electromagnetic Interference FIPS Federal Information Processing Standard GMT Greenwich Mean Time IBIP Information Based Indicia Program KAT Known Answer Test MAC Message Authentication Code NIST National Institute of Standards and Technology POST Power On Self Test PSD Postal Security Device PVD Postage Value Download PVR Postage Value Refund RAM Random Access Memory RNG Random Number Generator ROHS Restriction of Hazardous Substances ROM Read Only Memory SHA Secure Hash Algorithm Triple-DES Triple Data Encryption Standard © Copyright 2010 Pitney Bowes - Maxim Integrated Products Page 19 of 19 This document may be freely reproduced and distributed whole and intact including this Copyright Notice.