Red Hat Enterprise Linux 5 OpenSwan Cryptographic Module v1.0 FIPS 140-2 Security Policy version 1.7 Last Update: 2010-07-07 Red Hat Enterprise Linux 5 OpenSwan Cryptographic Module FIPS 140-2 Security Policy Version 1.6 Contents 1 Cryptographic Module Specification....................................................................................................................4 1.1 Description of Module .................................................................................................................................4 1.2 Description of Approved Mode ....................................................................................................................5 1.3 Cryptographic Module Boundary.................................................................................................................6 1.3.1 Hardware Block Diagram.....................................................................................................................7 1.3.2 Software Block Diagram......................................................................................................................8 2 Cryptographic Module Ports and Interfaces.........................................................................................................8 3 Roles, Services and Authentication ....................................................................................................................8 3.1 Roles........................................................................................................................................................... 9 3.2 Services....................................................................................................................................................... 9 3.3 Operator Authentication...............................................................................................................................9 3.4 Mechanism and Strength of Authentication.................................................................................................9 4 Physical Security...............................................................................................................................................10 5 Operational Environment...................................................................................................................................10 5.1 Policy......................................................................................................................................................... 10 6 Cryptographic Key Management.......................................................................................................................10 6.1 Key life cycle table.....................................................................................................................................10 6.2 Key Zeroization.......................................................................................................................................... 11 6.3 Random Number Generation.....................................................................................................................11 7 Electromagnetic Interference/Electromagnetic Compatibility (EMI/EMC)..........................................................12 8 Self Tests........................................................................................................................................................... 12 9 Guidance........................................................................................................................................................... 13 9.1 Cryptographic Officer Guidance.................................................................................................................13 10 Mitigation of Other Attacks...............................................................................................................................14 11 Glossary and Abbreviations.............................................................................................................................15 12 References...................................................................................................................................................... 16 © 2010 Red Hat / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 2 of 16 Red Hat Enterprise Linux 5 OpenSwan Cryptographic Module FIPS 140-2 Security Policy Version 1.6 Document History Version Date of Change Author Changes to Previous Version 0.1 2008-07-03 Steve Weingart atsec Initial version 1.0 2009-11-04 Steve Weingart atsec First release version 1.1-pre 2009-11-11 Steve Weingart atsec Correction of modutil call 1.2 2009-12-21 Steve Weingart atsec Add policy to guidance 1.3 2010-02-12 Steve Weingart atsec Update reference to OpenSWAN package RPM which includes bugfix RHBA:2010-0096 1.4 2010-04-13 Steve Weingart atsec Update single user mode statement 1.5 2010-06-14 Steve Weingart atsec Update of NSS CAVS certificates 1.6 2010-06-30 Steve Weingart atsec Update of SW block diagram 1.7 2010-07-07 Steve Weingart atsec Clarification of the CAVS certificate listing © 2010 Red Hat / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 3 of 16 Red Hat Enterprise Linux 5 OpenSwan Cryptographic Module FIPS 140-2 Security Policy Version 1.6 1 Cryptographic Module Specification This document is the non-proprietary security policy for the Red Hat Enterprise Linux 5 OpenSwan Cryptographic Module, and was prepared as part of the requirements for conformance to Federal Information Processing Standard (FIPS) 140-2, Level 1. The following section describes the module and how it complies with the FIPS 140-2 standard in each of the required areas. Description of Module The Red Hat Enterprise Linux 5 OpenSwan Cryptographic Module is a software only cryptographic module that provides the IKE protocol version 1 and version 2 key agreement services required for IPSec. The OpenSwan module is a software only, security level 1 cryptographic module, running on a multi-chip standalone platform. The following table shows the overview of the security level for each of the eleven sections of the validation. Security Component Security Level Cryptographic Module Specification 1 Cryptographic Module Ports and Interfaces 1 Roles, Services and Authentication 1 Finite State Model 1 Physical Security N/A Operational Environment 1 Cryptographic Key Management 1 EMI/EMC 1 Self Tests 1 Design Assurance 1 Mitigation of Other Attacks N/A Table 1: Security Levels The module has been tested on the following platforms: Manufacturer Model O/S & Ver. HP HP Integrity Server RX2660 Red Hat Enterprise Linux 5.4 (Single User Mode) HP HP ProLiant Server DL585 Red Hat Enterprise Linux 5.4 (Single User Mode) Table 2: Platforms Tested This cryptographic module combines a vertical stack of Linux components intended to limit the external interface each separate component may provide. The list of components and the cryptographic boundary of the composite module is defined as follows: • Red Hat Enterprise Linux 5 OpenSwan Cryptographic Module with the version of the RPM file of openswan-2.6.21-5.el5_4.3. • Network Security Service (NSS), a separately validated cryptographic module (FIPS 140-2 certificate © 2010 Red Hat / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 4 of 16 Red Hat Enterprise Linux 5 OpenSwan Cryptographic Module FIPS 140-2 Security Policy Version 1.6 #815) provides cryptographic algorithms and security functions for the Pluto IKE Daemon. The OpenSwan module uses this module in accordance with the Security Rules stated in the NSS Cryptographic Module Version 3.11.4 Security Policy. The RPM file that contains all of the files for the validated version of the Red Hat Enterprise Linux NSS Cryptographic module is version nss-3.12.6- 2.el5_4. The vendor affirmation covering the tested hardware platforms can be found at: http://www.redhat.com/solutions/government/certifications/. Note: The NSS version subject to validation was 3.11.4. As the NSS FIPS140-2 certificate does not cover the IA64 hardware architecture, the source code was recompiled, without any change, for the IA64 hardware platform. This is consistent with the vendor affirmation requirements in the FIPS 140-2 Implementation Guidance, G.5 item 1) a) i). • The module integrity check is performed by the Red Hat Enterprise Linux utility fipscheck supported by the associated library which is linked with the Pluto IKE Daemon. The version of the utility and its library is 1.2.0-1.el5. • The cryptographic services for the fipscheck utility are provided by the OpenSSL Cryptographic Module for standard cryptographic operations in the FIPS 140-2 level 1 validated version (FIPS 140-2 validation certificate #1320). This OpenSSL library provides the HMAC SHA-256 cryptographic mechanisms. The RPM file that contains all of the files for the validated version of the Red Hat Enterprise Linux OpenSSL Cryptographic module, used for the module integrity test, is version 0.9.8e-12.el5. This cryptographic boundary limits the external interface of the module to the interface provided by the Pluto daemon for the purposes of IKE. Therefore, it eliminates the need to protect cryptographic keys and other CSPs when crossing inter-component boundaries internal to the module. The module is a FIPS security level 1 software module. The Linux platform is constrained to be used by a single user. Description of Approved Mode The Red Hat Enterprise Linux 5 OpenSwan Cryptographic Module cryptographic boundary is defined by the following ciphers: Approved Algorithms provided by the NSS library (CMVP Certificate #815 with all other available cipher mechanisms are not enabled in the FIPS mode of the Pluto IKE Daemon): • Triple-DES (Cert# 943) • AES (Cert# 1368) • SHA-1 (Cert# 1250) • RNG (Cert# 755) • DSA (Cert# 449) • RSA (Cert# 669) Approved Algorithms provided by the OpenSSL library: • HMAC SHA-256 (Certs #661, #662 and #663) Caveat: The module will support the following non-approved functions. • Diffie-Hellman (key agreement, key establishment methodology provides between 80 bits and 112 bits of encryption strength) • EC Diffie-Hellman (key agreement, key establishment methodology provides between 80 bits and 256 bits of encryption strength) © 2010 Red Hat / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 5 of 16 Red Hat Enterprise Linux 5 OpenSwan Cryptographic Module FIPS 140-2 Security Policy Version 1.6 • RSA (key wrapping, key establishment methodology provides between 80 bits and 192 bits of encryption strength) The NSS library implements the following non-Approved algorithms, which shall not be used in the FIPS Approved mode of operation: • RC2 , RC4, or DES for symmetric key encryption and decryption. • MD2 or MD5 for hashing. Cryptographic Module Boundary The Red Hat Enterprise Linux 5 OpenSwan Cryptographic Module physical boundary is defined by the surface of the case of the platform tested on. The logical module boundary is depicted in the software block diagram and is embodied by the Pluto IKE Daemon and its supportive applications found at /usr/libexec/ipsec/ which link with the NSS library. The integrity check mechanism provided by the fipscheck application and the OpenSSL library are part of the cryptographic module but not depicted as they are only used during load time of the module. © 2010 Red Hat / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 6 of 16 Red Hat Enterprise Linux 5 OpenSwan Cryptographic Module FIPS 140-2 Security Policy Version 1.6 1.1.1 Hardware Block Diagram © 2010 Red Hat / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 7 of 16 Figure 1: Hardware Block Diagram Red Hat Enterprise Linux 5 OpenSwan Cryptographic Module FIPS 140-2 Security Policy Version 1.6 1.1.2 Software Block Diagram Note: This security policy only covers the user space module which includes the parts above the User/Kernel line in the block diagram below. 2 Cryptographic Module Ports and Interfaces Function Port Control In Network Port/Protocol, Configuration Files (/etc/ipsec.conf, /etc/ipsec.secrets), Linux Kernel (XFRM Interface), command line Status Out Log File, Network Port/Protocol Data In Network Port/Protocol, NSS Key Database file stored in /etc/ipsec.d/ Data Out Network Port/Protocol, Linux Kernel (XFRM Interface) Table 3: Ports and Interfaces 3 Roles, Services and Authentication This section defines the roles, services and authentication mechanisms and methods with respect to the © 2010 Red Hat / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 8 of 16 Figure 2: Software Block Diagram Red Hat Enterprise Linux 5 OpenSwan Cryptographic Module FIPS 140-2 Security Policy Version 1.6 applicable FIPS 140-2 requirements. Roles Role Services (see list below) User Encryption, Decryption (symmetric and public/private), Random Numbers Crypto Officer Configuration, Encryption, Decryption (symmetric and public/private), Random Numbers Table 4: Roles The user role is assumed by the underlying server application that makes calls to the module on behalf of one or more external clients [Reference: Implementation Guidance for FIPS PUB 140-2, dated 5-22-08, Section 6.1]. Services The module supports services that are available to users in the various roles. All of the services are described in detail in the module’s user documentation. The following table shows the services available to the various roles. Service Cryptographic Keys and CSPs Accessed Crypto Officer User Install and Configure the module. RSA public/private keys are added for SPD ● Manage Pluto IKE Daemon start, stop, etc. DRNG Seed and Seed Key Zeroize of CSPs, Keys ● Negotiate IKE to establish security associations DH private and public parameters RSA public/private used for authentication ISAKMP SA encryption key IPSEC SA encryption key ● ● Run the FIPS self test (initiation by restarting the module) N/A ● Read FIPS Status N/A ● Table 5: Operational Services Operator Authentication There is no operator authentication, assumption of role is implicit by action. Mechanism and Strength of Authentication No authentication is required at security level 1, authentication is implicit by assumption of the role. © 2010 Red Hat / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 9 of 16 Red Hat Enterprise Linux 5 OpenSwan Cryptographic Module FIPS 140-2 Security Policy Version 1.6 4 Physical Security This is a security level 1, software only module and does not claim any physical security. 5 Operational Environment This module will operate in a modifiable operational environment per the FIPS 140-2 definition. Policy The operating system shall be restricted to a single operator mode of operation (i.e., concurrent operators are explicitly excluded). The application that makes calls to the cryptographic module is the single user of the cryptographic module, even when the application is serving multiple clients. In the FIPS approved mode the ptrace(2) system call, the debugger (gdb(1)) and strace(1) shall not be used. 6 Cryptographic Key Management This section describes how keys and critical security parameters (CSP) are handled by the module. Cryptographic keys and CSPs are never output from the module in plaintext. An Approved key generation method is used to generate keys that are generated by the module via NSS. Key life cycle table Key Type Generation Establishment Access by Service Entry and output method Storage Zeroization RSA Private and Public Keys RSA key N/A N/A Authentication in the ISAKMP SA negotiation N/A Plaintext Immediately after use by NSS ISAKMP Security Association Tunnel Encryption Keys AES or Triple-DES N/A Established during the ISAKMP SA handshake using DH. Establish & Maintain ISAKMP SA N/A Ephemeral Close of ISAKMP SA or termination of Pluto IKE Daemon IPSEC Security Association Tunnel Encryption Keys AES or Triple-DES N/A Established during the IPSEC SA handshake using DH. Establish & Maintain IPSEC SA Transfer to the Linux Kernel via XFRM Interface Ephemeral Close of ISAKMP SA or overwritten by re- negotiated IPSEC SA or termination of Pluto IKE Daemon © 2010 Red Hat / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 10 of 16 Red Hat Enterprise Linux 5 OpenSwan Cryptographic Module FIPS 140-2 Security Policy Version 1.6 Key Type Generation Establishment Access by Service Entry and output method Storage Zeroization Diffie-Hellman Private and Public Parameters DH ANSI FIPS 186-2 RNG N/A Establish & Maintain ISAKMP SA and IPSEC SA N/A Ephemeral Close of ISAKMP SA or termination of Pluto IKE Daemon RNG Seed random value N/A N/A Establish & Maintain ISAKMP SA and IPSEC SA N/A, provided by /dev/uran dom Ephemeral N/A (Termination of Pluto IKE Daemon where NSS zeroizes seed) RNG Seed Key random value N/A N/A Establish & Maintain ISAKMP SA and IPSEC SA N/A, provided by /dev/uran dom Ephemeral N/A (Termination of Pluto IKE Daemon where NSS zeroizes key) Software Integrity Key for OpenSSL, fipscheck and all Pluto IKE applications HMAC SHA-256 N/A N/A Self-Tests N/A Plaintext within the OpenSSL and fipscheck libraries Termination of the fipscheck application Software Integrity Key for NSS library DSA N/A N/A Self-Tests N/A Plaintext within the NSS library Termination of Pluto IKE Daemon Table 6: Key Life Cycle Notes: Private keys are always encrypted by the NSS library. When an operation, requires a private key, the first pointer or handle to the private key is obtained using the public key and CKAID. Only during the operation private keys are decrypted and the operation is performed. After the operation is over, the memory pointing to the private key is zeroized by NSS. Until the private keys from the NSS database need to be deleted, there is special zeroization required – for details about the maintenance of keys by the NSS library, see CMVP certificate #815. Key Zeroization For volatile memory, memset is included in deallocation operations. There are no restrictions when zeroizing any cryptographic keys and CSPs. Random Number Generation The module employs a FIPS186-2 x-Change Notice and a FIPS186-2 General Purpose x-Change Notice PRNG provided by the NSS library, which is seeded by the kernel. © 2010 Red Hat / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 11 of 16 Red Hat Enterprise Linux 5 OpenSwan Cryptographic Module FIPS 140-2 Security Policy Version 1.6 The Linux kernel provides /dev/urandom as a source of random numbers for RNG seeds. The Linux kernel initializes this pseudo device at system startup. The kernel performs continual tests on the random numbers it uses to ensure that the seed and seed key input to the Approved RNG do not have the same value. The kernel also performs continual tests on the output of the approved RNG to ensure that consecutive random numbers do not repeat. 7 Electromagnetic Interference/Electromagnetic Compatibility (EMI/EMC) Product Name and Model: HP ProLiant Server DL585 Series Regulatory Model Number: HSTNS-1025 Product Options: All conforms to the following Product Specifications and Regulations: EMC: Class A CISPR 22:2005 EN 55022:2006 EN 55024:1998 +A1:2001 +A2:2003 EN 61000-3-2:2006 EN 61000-3-3:1995 +A1:2001 +A2:2005 Product Name and Model: HP Integrity Server rx2660 Regulatory Model Number: RSVLA-0503 Product Options: All conforms to the following Product Specifications and Regulations : EMC: Class A CISPR22:1997 / EN 55022:1998 CISPR 24:1997 + A1:2001 + A2: 2002 / EN 55024:1998 + A1:2001 + A2:2003 EN 61000-3-2:2000 EN 61000-3-3:1995 +A1:2001 8 Self Tests FIPS 140-2 requires that the module perform self tests to ensure the integrity of the module and the correctness of the cryptographic functionality at start up. In addition some functions require continuous verification of function, such as the random number generator. All of these tests are listed and described in this section. The module performs both power-on self test (POST) and conditional self tests to verify the integrity and correct operational functioning of the cryptographic module. If the system fails a self test, it reports status indicating that a failure has occurred and transitions to an error state, blocking all data input, data output and control input via their respective interfaces. While the module is performing any power on self test or conditional test, software rules within the executable image prevent the module from entering a state where data output via the data output interface is possible. The crypto officer with physical or logical access to the module can run the POST on demand by power cycling the module or by rebooting the operating system. The following table summarizes the system self tests and conditional tests. © 2010 Red Hat / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 12 of 16 Red Hat Enterprise Linux 5 OpenSwan Cryptographic Module FIPS 140-2 Security Policy Version 1.6 Self Test Description Mandatory power-up tests performed at power-up and on demand: Cryptographic Algorithm Known Answer Tests Each cryptographic algorithm (see section1.1 for algorithm list) performed by the module, is tested using a “known answer” test to verify the correct operation of the algorithm. These tests are performed by the NSS library before it makes itself available to the Pluto IKE Daemon. In addition, the HMAC SHA-256 KAT is performed by the Red Hat Enterprise Linux OpenSSL library. HMAC SHA-256 is only used for the integrity check. Integrity Test The module computes an HMAC SHA-256 value for the the OpenSSL library, the fipscheck utility and all applications forming the OpenSwan (this) module and compares it to a pre-calculated value stored within the system. The integrity check is performed by the Red Hat Enterprise Linux OpenSSL Cryptographic Module utility fipscheck using OpenSSL for the HMAC SHA-256 implementation. The integrity verification of the NSS library is performed by the NSS library using DSA. Critical Functions tests performed at power-up: None No security-relevant critical functions tests are performed. Conditional tests performed, as needed, during operation: Continuous RNG 16 bits continuous testing is performed during each use of the approved RNG. This test is a “stuck at” test to check the RNG output data for failure to a constant value. Table 7: Self Tests Any self test success or failure messages are output to the Pluto IKE Daemon error log file. Known answer tests for encryption/decryption or hashing, function by encrypting or hashing a string for which the calculated output is known and stored within the cryptographic module. An encryption or hashing test passes when the freshly calculated output matches the expected (stored) value. A test fails when the calculated output does not match the expected value. For decryption, the test then decrypts the ciphertext encrypted string. A decryption test passes when the freshly calculated output matches the plaintext value. A decryption test fails when the calculated output does not match the plaintext value. Known answer tests for Random Number Generators function by seeding the RNG with known values and checking that the output matches the pre-calculated value stored within the cryptographic module. The test passes when the freshly generated output matches the pre-calculated value. A test fails when the generated output does not match the pre-calculated value. 9 Guidance The following section provides guidance for the Crypto Office for using the module in a way that maintains compliance with FIPS 140-2. No specific guidance for the user is to be provided as the user actions do not have an impact to the maintenance of a secure operational state of the module. Cryptographic Officer Guidance NOTE: All cryptographic functions for the Red Hat Enterprise Linux 5 OpenSwan Cryptographic Module will be © 2010 Red Hat / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 13 of 16 Red Hat Enterprise Linux 5 OpenSwan Cryptographic Module FIPS 140-2 Security Policy Version 1.6 provided by a copy of a FIPS 140-2 validated version of the Red Hat NSS library. The OpenSSL library is used to perform integrity verification. • Configure pluto as specified in ipsec.conf(5) and ipsec.secrets(5) man pages as well as the file README.nss provided by the OpenSwan RPM package. • The correct policy for the RHEL5.4 validated version is selinux-policy-2.4.6-255.el5_4.2.noarch • To start and stop the module, use the (service ipsec) command. • Stopping the module will zeroize the ephemeral CSPs and keys. • To check FIPS 140-2 module status, read the pluto debug data using the ipsec_barf(8) tool. • The version of the RPM containing the validated module is stated in section1.1 above. The integrity of the RPM is automatically verified during the installation and the Crypto officer shall not install the RPM file if the RPM tool indicates an integrity error. • Pre-shared Keys are not supported and shall not be used in FIPS mode. • Only the FIPS 140-2 approved and allowed ciphers listed in section 1.1 shall be used in configuring the pluto daemon. • When zeroizing the module the crypto officer is responsible for using a FIPS140-2 approved mechanism to clear the keys written on disk. • The database for the cryptographic keys used by the pluto daemon must be initialized after it has been created as documented in the README.nss documentation with the following command assuming that the database is stored in the directory /etc/ipsec.d/ ◦ modutil -fips true -dbdir /etc/ipsec.d NOTE: Encryption and decryption of data is done implicitly when the kernel triggers pluto to set up a new Security Association. For proper operation of the in-module integrity verification, the prelink has to be disabled. This can be done by setting PRELINKING=no in the /etc/sysconfig/prelink configuration file. To bring the module into FIPS mode, the crypto officer has to regenerate the initrd by using the following command: For the x86_64 platform, the command is: mkinitrd --with-fips -f /boot/initrd-$(uname -r).img $(uname -r) For the IA64, the command is: mkinitrd --with-fips -f /boot/efi/efi/redhat/initrd-$(uname -r).img $(uname -r) After regenerating the initrd, the crypto officer has to append the following string to the kernel command line by changing the setting in the boot loader: fips=1 This operation causes the FIPS flag to be set by the kernel which can be read in /proc/sys/crypto/fips_enabled (if the file contains a 1, the FIPS mode is enabled – a 0 specifies a disabled FIPS mode). 10 Mitigation of Other Attacks No other attacks are mitigated. © 2010 Red Hat / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 14 of 16 Red Hat Enterprise Linux 5 OpenSwan Cryptographic Module FIPS 140-2 Security Policy Version 1.6 11 Glossary and Abbreviations AES Advanced Encryption Specification CAVP Cryptographic Algorithm Validation Program CBC Cypher Block Chaining CCM Counter with Cipher Block Chaining-Message Authentication Code CFB Cypher Feedback CC Common Criteria CMT Cryptographic Module Testing CMVP Cryptographic Module Validation Program CSP Critical Security Parameter CVT Component Verification Testing DES Data Encryption Standard DSA Digital Signature Algorithm EAL Evaluation Assurance Level ECB Electronic Code Book FSM Finite State Model HMAC Hash Message Authentication Code LDAP Lightweight Directory Application Protocol MAC Message Authentication Code NIST National Institute of Science and Technology NVLA P National Voluntary Laboratory Accreditation Program OFB Output Feedback O/S Operating System PP Protection Profile RNG Randome Number Generator RSA Rivest, Shamir, Addleman SAP Service Access Points SDK Software Development Kit SHA Secure Hash Algorithm SHS Secure Hash Standard SLA Service Level Agreement SNMP Simple Network Management Protocol SOF Strength of Function SSH Secure Shell © 2010 Red Hat / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 15 of 16 Red Hat Enterprise Linux 5 OpenSwan Cryptographic Module FIPS 140-2 Security Policy Version 1.6 SVT Scenario Verification Testing TDES Triple DES TOE Target of Evaluation UI User Interface Table 8: Abbreviations 12 References [1] Open Swan user guide (provided with installation RPM, see section 1.1 Description of Module for version) [2] rx2660_EMIEMC_cert.pdf (On file at Red Hat) [3] DL585_EMIEMC_CEcert.pdf (On file at Red Hat) [4] FIPS 140-2 Standard, http://csrc.nist.gov/groups/STM/cmvp/standards.html [5] FIPS 140-2 Implementation Guidance, http://csrc.nist.gov/groups/STM/cmvp/standards.html [6] FIPS 140-2 Derived Test Requirements,http://csrc.nist.gov/groups/STM/cmvp/standards.html [7] FIPS 197 Advanced Encryption Standard, http://csrc.nist.gov/publications/PubsFIPS.html [8] FIPS 180-3 Secure Hash Standard, http://csrc.nist.gov/publications/PubsFIPS.html [9] FIPS 198-1 The Keyed-Hash Message Authentication Code (HMAC), http://csrc.nist.gov/publications/PubsFIPS.html [10] FIPS 186-3 Digital Signature Standard (DSS), http://csrc.nist.gov/publications/PubsFIPS.html [11] ANSI X9.52:1998 Triple Data Encryption Algorithm Modes of Operation, http://webstore.ansi.org/FindStandards.aspx?Action=displaydept&DeptID=80&Acro=X9&DpName=X9,%20Inc. © 2010 Red Hat / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 16 of 16