Federal Information Processing Standard (FIPS) 140-2 Good Technology, Inc. FIPSCrypto on Windows Mobile Version 4.7.0.50906 FIPS 140-2 Non-Proprietary Security Policy FEBRUARY 8, 2006 ©Good Technology, Inc. 2006. All rights reserved. Good, Good technology, the Good logo and GoodLink are trademarks of Good Technology, Inc. in the United States and/or other countries. Good Technology, Inc., and its products are not related to, sponsored by, or affiliated with Research In Motion Limited. All other trademarks and service marks contained herein are the property of their respective owners. This document maybe freely reproduced and distributed whole and intact including this Copyright Notice 2 DOCUMENT VERSION CONTROL VERSION DATE AUTHOR (S) DESCRIPTION REASON FOR CHANGE 1.0 11 Jan 2004 Prathaban Selvaraj Initial Version Good Technology 1.1 06 Aug 2005 Richard Modifications for Levenberg Windows CE 4.2 Good Technology 1.2 20 Sept 2005 Richard Key Zeroization Update for Key Levenberg update Zeroization Good Technology 1.3 13 Oct 2005 Richard Minor edits Levenberg Good Technology 1.4 25 Oct 2005 Rory Saunders Minor edits Incorporated CEAL, previous CygnaCom NIST/CSE Solutions, Inc. comments 1.5 08 Feb 2006 Rory Saunders Minor edits Incorporated CEAL, previous CygnaCom NIST/CSE Solutions, Inc. comments 3 TABLE OF CONTENTS 1. INTRODUCTION..................................................................................................... 5 1.1 PURPOSE .............................................................................................................. 5 1.2 REFERENCES ........................................................................................................ 5 2. CRYPTOGRAPHIC MODULE SPECIFICATION ............................................. 5 3. CRYPTOGRAPHIC MODULE PORTS AND INTERFACES ........................... 6 4. ROLES, SERVICES AND AUTHENTICATION ................................................. 7 4.1 ROLES .................................................................................................................. 7 4.1.1 The Crypto-Officer Role ............................................................................. 7 4.1.2 The User Role ............................................................................................. 8 4.2 SERVICES ............................................................................................................. 9 4.2.1 Approved Mode Of Operation .................................................................. 11 4.3 AUTHENTICATION .............................................................................................. 11 5. PHYSICAL SECURITY ........................................................................................ 11 6. OPERATIONAL ENVIRONMENT..................................................................... 11 7. CRYPTOGRAPHIC KEY MANAGEMENT...................................................... 12 7.1 KEY GENERATION.............................................................................................. 12 7.2 KEY INPUT/OUTPUT ........................................................................................... 12 7.3 KEY STORAGE.................................................................................................... 12 7.4 KEY ZEROIZATION ............................................................................................. 12 7.5 CRYPTOGRAPHIC ALGORITHMS ......................................................................... 12 8. EMI/EMC ................................................................................................................ 13 9. SELF TESTS ........................................................................................................... 13 10. MITIGATION OF OTHER ATTACKS .............................................................. 13 11. SECURE OPERATION ......................................................................................... 13 4 1. Introduction 1.1 Purpose The FIPSCrypto on Windows Mobile cryptographic module is a Software Dynamic Link Library (DLL) module that implements the Triple-DES, AES, SHA-1 and HMAC-SHA-1 algorithms. This non-proprietary Security Policy describes how the crypto module meets the security requirements of FIPS 140-2 Level 1 and how to securely operate the module. The cryptographic module enables the GoodLinkTM wireless corporate messaging system to securely establish a continuously synchronized wireless connection to corporate systems. Users can instantly access up-to-date corporate email; secure attachments, contacts, calendar, notes and tasks, and other information when traveling. 1.2 References For more information on Good Technology and the GoodLink product visit http://www.good.com. Detailed information on the FIPS140-2 standard can be found at the NIST web site, http://csrc.nist.gov/cryptval. 2. Cryptographic Module Specification The FIPSCrypto on Windows Mobile, version 4.7.0.50906 is validated against FIPS 140- 2 Level 1 to run on Windows CE 4.2 devices. The cryptographic module is a software- only module. The module was tested on a Motorola MPx220 device running a Windows CE operating system version 4.2. The module is classified as a multi-chip standalone module. The logical cryptographic boundary contains the software modules that comprise the FIPSCrypto dynamic link library. The physical boundary of the module is defined as the enclosure of the handheld on which the module executes. 5 3. Cryptographic Module Ports And Interfaces The physical ports to the cryptographic module are standard I/O ports found on the handheld device such as a USB port, wireless infrared radio, and Graphical Display controller. The logical interface to the module is an Application Programming Interface (API). The function calls, that represent the services provided by the module, act as the Control Input Interface. The parameters to the API act as the Data Input Interface. The parameters returned from the API act as the Data Output Interface. The Status Output interface is the error code and return values provided by each function in the API. Interface Logical Interface Physical Port Data Input Parameters to the API Wireless Infrared Radio, Key Pad controller, Graphical Display Controller, USB Port, SD slot port, microphone port, camera port Data Output Parameters returned from the API Wireless Infrared Radio, Key Pad Controller, Graphical Display Controller, USB port, SD slot port, speaker/earpiece/headset port Control Input Exported API calls Key Pad Controller, button controller, USB port Status Output Error code and return values provided by Wireless Infrared Radio, each function in the API Graphical Display Controller, speaker/earpiece/headset port Power N/A Battery Port Table 1. Ports And Interface Mapping Interface Parameters Data Input Key, Key Length, Algorithm Context, Plain text, Cipher-text, Encode/Decode flag, IV, IV Length, Plain text Length, Cipher-text Length, Padding Mode, Counter, Counter length, Hash Input Data, Hash Input Data Length, Num Bytes, Buffer size Data Output Cipher-text block, Algorithm Context, Plain text block, Context, Cipher- 6 text, Cipher-text Len, Plaintext, Plaintext Len, Digest, MAC value Control Input Aes_enc_key, Aes_enc_blk, Aes_dec_Key, Aes_dec_blk, SetKey, SetIV, SetCtr, Encode, Decode, getOutputLen, A_DES_EDE3_CBCEncryptInit, A_DES_EDE3_CBCEncryptyUpdate, A_DES_EDE3_CBCEncryptFinal, A_DES_EDE3_CBCDecryptInit, A_DES_EDE3_CBCDecryptUpdate, A_DES_EDE3_CBCDecryptFinal, A_SHAInit, A_SHAUpdate, A_SHAFinal, A_SHACopyContext, SetKey, GetMAC, GetMAC_N Status Output Getfipsenabled, Getfipstestsrun, Getfipstestspassed CRYPTOERR_OK, CRYPTOERR_INVALIDENCODEKEY, CRYPTOERR_INVALIDDECODEKEY, CRYPTOERR_INVALIDKEY, CRYPTOERR_INVALIDDATA, CRYPTOERR_INVALIDIV, CRYPTOERR_INVALIDPADDING, CRYPTOERR_ENCODEFAIL, CRYPTOERR_DECODEFAIL, CRYPTOERR_INVALIDCTR, CRYPTOERR_BUFFERTOOSMALL, CRYPTOERR_FAIL, CRYPTOERR_INVALIDHMACKEY, CRYPTOERR_CANCEL, AE_OUTPUT_LEN, AE_INPUT_LEN Table 2. Interface And Parameter Mapping 4. Roles, Services and Authentication 4.1 Roles The cryptographic module is a single operator software module that supports two authorized roles. Roles User Role Crypto-Officer Role Table 3. Roles 4.1.1 The Crypto-Officer Role The operator takes on the role of a Crypto-Officer to perform tasks like, module installation and zeroization of the module. Other tasks performed by the Crypto-Officer include key entry, initiate the power-on self-tests on demand and check the status of the cryptographic module. The Crypto-Officer role has authorized access to the Triple-DES, AES, SHA-1 and HMAC-SHA-1 algorithms. 4.1.1.1 The Crypto-Officer Guide 7 The GoodLink Desktop Software is used by the Crypto-Officer to install the cryptographic module onto the handheld device in a secure environment using the USB port. The Crypto-Officer starts up the Desktop Software and connects the handheld to the USB port. The Crypto-Officer then starts the software installation process that copies the cryptographic module onto the handheld. Keys are installed onto the handheld as a part of this process. Upon completion of the installation process the module performs its power- on self-tests and enters an initialized state or error state. The Crypto-Officer can then request services from the module. The Crypto-Officer has the exclusive rights to perform Key Entry operations. 4.1.2 The User Role An operator can assume the User Role and access the cryptographic algorithms provided in the module, which are AES, Triple-DES, SHA-1 and HMAC-SHA-1. 4.1.2.1 The User Guide The User can request services from the cryptographic module using the module's Logical interface. The User Role has authorized access to the Triple-DES, AES, SHA-1 and HMAC-SHA-1 algorithms. The User can also initiate self-tests and check the status of the module. The cryptographic module provides information about the status of a requested operation to the user through the Status Output Interface. The following status codes are defined for the module. Status Codes Information CRYPTOERR_OK Operation completed successfully. CRYPTOERR_INVALIDENCODEKEY The key used for performing encryption operations is invalid. CRYPTOERR_INVALIDDECODEKEY The key used for performing decryption operations is invalid. CRYPTOERR_INVALIDKEY The key used for performing cryptographic operations is invalid. CRYPTOERR_INVALIDDATA The input data passed to the cryptographic module is invalid. CRYPTOERR_INVALIDIV The Initialization Vector input to the module is invalid. CRYPTOERR_INVALIDPADDING The padding of the encrypted blob is invalid. CRYPTOERR_ENCODEFAIL The encryption operation failed. CRYPTOERR_DECODEFAIL The decryption operation failed. CRYPTOERR_INVALIDCTR The Counter value input to the module is invalid. CRYPTOERR_BUFFERTOOSMALL The size of the buffer passed to the module 8 is too small to perform the requested operation. CRYPTOERR_INVALIDHMACKEY The key used by the HMAC-SHA-1 is invalid. CRYPTOERR_CANCEL The module is in an error state. Check if the power-on self-tests have passed. CRYPTOERR_FAIL The module is in an error state. Check if the power-on self-tests have passed. AE_CANCEL The module is in an error state. Check if the power-on self-tests have passed. AE_OUTPUT_LEN The size of the buffer passed to the module is too small to perform the requested operation. AE_INPUT_LEN The size of the input data is invalid. FIPS enabled : True The module is in the FIPS mode and sets its FIPSenabled flag to True. FIPS tests run : True The module performs its self-tests and sets the FIPStestsrun flag to True. FIPS tests passed : True The module has successfully passed the FIPS self tests and sets its FIPStestspassed flag to true. Table 4. Status Codes The operator of the module can also determine its status from the debugger screen. Enter the debugger screen by typing `DEBUG' on the keypad and then type `fips' on the command line and . Each of the modules' API functions is tested and the results are printed to the screen. 4.2 Services The services provided by the cryptographic module are listed in the following table. Services Cryptographic Keys Role (CO, User, Both) Access (R/W/X) and CSPs AES Encryption AES secret Key CO, User X AES Encryption: AES secret Key CO X Key Entry AES Decryption AES secret Key CO, User X AES Decryption: AES secret Key CO X Key Entry Triple-DES Encryption Triple-DES secret Key CO, User X Triple-DES Encryption: Triple-DES secret Key CO X Key Entry 9 Triple-DES Decryption Triple-DES secret Key CO, User X Triple-DES Decryption: Triple-DES secret Key CO X Key Entry SHA-1 Hashing N/A CO, User X HMAC-SHA-1 HMAC-SHA-1 Key CO, User X HMAC-SHA-1: HMAC-SHA-1 Key CO X Key Entry Show Status N/A CO, User X Perform Self tests N/A CO, User X Table 5. Services, Roles, Access The following table presents a mapping of each cryptographic service provided by the module to its logical interface and the role assumed by the operator of the module to request those services. Service Logical Interface Role AES Encryption aescrypt.c : aes_enc_blk User, CO aescbc.cpp : Encode aescbc.cpp : SetIV aescbc.cpp : getContext aesctr.cpp : SetCtr aesctr.cpp : getContext aesctr.cpp : Encode aesctr.cpp : getOutputLen AES Encryption: aescrypt.c : aes_enc_key CO Key Entry aescbc.cpp : SetKey aesctr.cpp : SetKey AES Decryption aescrypt.c : aes_dec_blk User, CO aescbc.cpp : Decode aescbc.cpp : SetIV aescbc.cpp : getContext aesctr.cpp : SetCtr aesctr.cpp : getContext aesctr.cpp : Encode aesctr.cpp : getOutputLen AES Decryption: aescrypt.c : aes_dec_key CO Key Entry aescbc.cpp : SetKey aesctr.cpp : SetKey Triple-DES desedee.cpp : A_DES_EDE3_CBCEncryptInit CO Encryption: Key Entry Triple-DES desedee.cpp : A_DES_EDE3_CBCEncryptUpdate User, CO Encryption desedee.cpp : A_DES_EDE3_CBCEncryptFinal Triple-DES deseded.cpp : A_DES_EDE3_CBCDecryptInit CO 10 Decryption: Key Entry Triple-DES deseded.cpp : A_DES_EDE3_CBCDecryptUpdate User, CO Decryption deseded.cpp : A_DES_EDE3_CBCDecryptFinal SHA-1 Hashing gdsha.cpp : A_SHAInit User, CO gdsha.cpp : A_SHAUpdate gdsha.cpp : A_SHAFinal gdsha.cpp : A_SHACopyContext HMAC-SHA-1 Sha1HMAC.cpp : GetMAC User, CO Sha1HMAC.cpp : GetMAC_N HMAC-SHA-1: Sha1HMAC.cpp : SetKey CO Key Entry Show Status FipsCryptoPPC.cpp : getfipsenabled User, CO FipsCryptoPPC.cpp : getfipstestspassed FipsCryptoPPC.cpp : getfipstestsrun Self Tests FipsCryptoPPC.cpp : InitializeFips User, CO Table 6. Services And Logical Interface Mapping 4.2.1 Approved Mode Of Operation The module only provides an Approved Mode Of Operation. No special configuration is required to operate the module in a FIPS 140-2 mode. In this mode all authorized roles can call the FIPS 140-2 approved algorithms and services. 4.3 Authentication The cryptographic module is validated at FIPS 140-2 Level 1 and does not provide role authentication for the authorized roles. The operator assumes these roles implicitly when invoking these services. 5. Physical Security The cryptographic module is a software module that operates on the Windows CE 4.2 platform. The Windows CE 4.2 handheld devices use production grade components. 6. Operational Environment The operational environment consists of Windows CE 4.2, a pre-emptive multi-tasking operating system running on an ARM-based processor. 11 7. Cryptographic Key Management 7.1 Key Generation The cryptographic module does not perform key generation. 7.2 Key Input/Output The keys are electronically input into the module in plain-text form by the Crypto- Officer. Keys are not output from the module. 7.3 Key Storage The module does not provide persistent storage for the keys used by the algorithms. The HMAC-SHA-1 key used for the integrity check is hard-coded into the module's executable code. 7.4 Key Zeroization The keys are stored in memory on the device during the execution of an encryption/decryption or HMAC-SHA-1 calculation. At the completion of the calculation, the keys are zeroized. The other key is the HMAC-SHA-1 key used to perform the integrity check. The operator can zeroize this key by hard resetting the device on which the cryptographic module is operating. 7.5 Cryptographic Algorithms The algorithms implemented by this module are listed below. Algorithm Certificate Number Triple-DES (Triple Data Encryption # 240 Standard) AES (Advanced Encryption Standard) # 134 SHA-1 (Secure Hash Algorithm) # 217 HMAC-SHA-1 (Keyed-Hashing Message # 126 Authentication Code) 12 8. EMI/EMC The cryptographic module is a software module. The module runs on Windows CE 4.2 devices. The tested device meets applicable Federal Communication Commission (FCC) Electromagnetic Interference and Electromagnetic Compatibility requirements for business use. 9. Self Tests Power On Tests The cryptographic module performs algorithmic self-tests at startup time to ensure that the module is functioning properly. It also performs an integrity check using an approved HMAC-SHA-1 algorithm to validate the integrity of the module. These tests are initiated without user intervention at startup time or can be initiated by the user by restarting the device. The self-tests consist of a set of known answer tests to validate the working of the AES, Triple-DES, SHA-1 and HMAC-SHA-1 algorithms. 10. Mitigation Of Other Attacks The module is not designed to mitigate any other attacks. 11. Secure Operation A configuration management system is set up using CVS (Concurrent Versioning System) to identify each component of the cryptographic module including documentation using a unique identification number. The Crypto-Officer installs the cryptographic module in FIPS 140-2 mode in a secure environment. The module implements only FIPS 140-2 approved algorithms and hence all cryptographic services provided by the module are FIPS 140-2 compliant. All the critical security functions performed by the module are tested at start-up or on demand. The module's integrity is also tested to prevent tampering, using an approved HMAC-SHA-1 algorithm. 13