Blue Ridge Networks BorderGuard 4000/3140 FIPS 140-2 Security Policy Version 2.0 Copyright 2004 Blue Ridge Networks, Inc. This document may be freely reproduced and distributed whole and intact provided this Copyright Notice is included. -1- 1.0 Introduction 3 1.1 Identification 3 1.2 Description 3 2.0 Device Description 4 2.1 Interfaces 4 2.2 Firmware 5 2.3 Cryptographic Boundary 6 2.4 States 6 2.5 Processors 6 2.6 Firmware Security 6 2.7 Embedded Control Program 6 3.0 Identification and Authentication Policy 7 3.1 Crypto-officer 7 3.2 User 7 3.3 Policy Definition 8 4.0 Access Control Policy 9 4.1 Access to Critical Security parameters 9 4.2 Key Management 10 4.3 Key Protection 12 4.4 Key Destruction 12 4.5 Random Number Generation 13 4.6 Cryptographic Algorithms 13 5.0 Physical Security Policy 14 6.0 Mitigation of Other Attacks 15 6.1 Replay Prevention 15 6.2 Denial of Service Attacks 16 6.3 Tamper resistant screws 16 7.0 Self-Tests 16 7.1 Mandatory tests 16 7.2 Conditional Tests 16 7.3 Optional self-tests 17 7.4 Failure of self-test 17 Glossary of Acronyms 18 -2- BorderGuard 4000/3140 Security Policy 1.0 Introduction This document defines the security rules under which this product operates. The rules are enforced by the use of firmware modules. The use of the firmware is mandatory and is called automatically while exercising the module. 1.1 Identification Hardware BorderGuard 4000, BorderGuard 3140 Version: DPF1 V6.2 Firmware BG4000 Firmware Version DPF1 V6.2 Vendor: Blue Ridge Networks 14120 Parke Long Court, Suite 201 Chantilly, VA 20151 1.2 Description The BorderGuard 4000 and BorderGuard 3140 (henceforth abbreviated BG4000) is a standalone Internet security appliance that takes the form of an electronic hardware device containing a processor, memory, networking and crypto components, and firm- ware. The BorderGuard 3140 differs from the more common BorderGuard 4000 in only one respect: reduced performance of the device through restrictions on the use of data cache. In addition, the BorderGuard 4000 may be purchased with a USB authentication token that will activate only a spe- cific chassis when inserted in the unit. Both units are otherwise identical, run the same firmware, have a common hardware and firmware Cryptographic Module, and have the same hardware com- plement. The BG4000 is a multi-function appliance that can perform many non-cryptographic network func- tions such as multi-protocol routing, bridging, and packet filtering. The cryptographic component and Cryptographic Module of the unit is often referred to in this document by its trade name, Data Privacy Facility (DPF.) The BG4000 is typically installed so that it forwards network data packets entering and exiting a site or secure enclave. Using a Forwarding Policy specified by the Crypto-Officer, it selectively trans- forms network packets inbound or outbound to a remote site/enclave or an individual user's host. It thus operates as a Virtual Private Network device capable of: · Securing traffic between sites within an organization, or between two separate organizations. · Securing access between a site and an individual remote user (remote access). Externally, it interconnects three Ethernet Local Area Networks, and is able to exercise a Security Policy on Internet data packets (IP datagrams) that would normally flow between the connected net- works. In addition to its network interfaces, it provides a control and status interface through a serial console port that is, at the Crypto-officer's discretion, accessible through Internet services such as Telnet. -3- BorderGuard 4000/3140 Security Policy 2.0 Device Description The module is a multi-chip standalone embodiment, housed within a 1-unit high sheet metal chassis, protected by tamper evident seals and tamper proof screws. There are no user or administrator ser- viceable or configurable items inside the chassis. There is no reason for the customer to open the chassis, which must be returned to the factory should maintenance be required. The tamper evident seals must be inspected periodically to detect tampering. The BG4000 device and BG4000 Cryptographic Module conform to FIPS 140-2 Level 2. The module also conforms with the EMI/EMC requirements in FCC Part 15, Subpart J, Class A. 2.1 Interfaces · Ethernets. The BG4000's three Ethernet ports use an industry standard 100BaseT connector consisting of an RJ45 jack and four grounded signal lines. · Serial Interface. The serial interface may be used for console access by the Crypto- officer, and is a 9 pin RS-232C serial connector. FIGURE 1. BorderGuard 4000 Physical External Interfaces Power input Data input Data output Control input Status Output BorderGuard 3140 and 4000 Back Panel ETHERNETS 1 EN03 EN02 EN01 CONSOLE 0 Control input Status output BorderGuard 4000 Front Panel LCD DISPLAY USB Data input Status output BorderGuard 3140 Front Panel LCD DISPLAY Status output -4- BorderGuard 4000/3140 Security Policy · USB Port. (BG4000 only) The USB port is used in applications where the entire unit is mated to a USB token, and the BorderGuard will refuse to boot if the unique authentication token is not installed in the USB socket at boot time. · AC Power. The unit has an industry standard power connector that can accept 50- 60Hz, 110-230 VAC power. · LCD Display. A 2x24 line alphanumeric LCD display gives unit status and statistics. There are no accessible doors or openings. The chassis cover and access to a factory maintenance port are secured with tamper resistant screws and tamper evident tape. 2.2 Firmware The module is designed to execute four major firmware components,: · Boot Code, which is designed to Self Test the unit, and load Functional Firmware that performs the Operating System, Packet Forwarding, and Cryptographic Mod- ule functions. · Operating System Functional Firmware, which provides the core services needed to manage memory, dispatch tasks, service interrupts, and provide file I/O and console access. FIGURE 2. BG4000/3140 Firmware Components BorderGuard Control Program Initialization Executive Utilities Scheduler Filesystems Console Power On FTP Client Tasks Self Tests Memory Signals Parser TFTP Client Management Load options and Timer Dump, diagnostics Services Trace Telnet Client Console TCP/IP, Telnet Services Sockets Server Forwarding Module IP Route Manager Bridge Forwarding Driver Filtering Driver Incoming Ethernet Transmitted Packets IP Routing Ethernet Packets Cryptographic Boundary BG4000 Cryptographic Module Authorization Packet Packet Task Decoding Encoding (Session Management) Codec -5- BorderGuard 4000/3140 Security Policy · Packet Forwarding Functional Firmware (forwarding module), which controls the network media interfaces, performs a variety of Internet and LAN based packet for- warding procedures, and can selectively identify packets for implementation of a Security Policy through filtering and port selection mechanisms. The detailed oper- ation of the packet forwarding firmware is not discussed in this document. · Cryptographic Functional Firmware, which is the BG4000 Cryptographic Module to which this Security Policy applies. This component executes the cryptographic func- tions. 2.3 Cryptographic Boundary The physical cryptographic boundary for the module consists of the entire Border- Guard chassis, including all circuit boards and components thereon, power supplies, interfaces, indicator lamps and chassis sheet metal. The unit is designed for rack mounting and is 18" x 12" x 1.75". 2.4 States The BG4000 Cryptographic Module is designed as a finite state machine. The basic states are Power off, Boot, Initialization, Operating, and Error. 2.5 Processors The code is executed on a Motorola MPC8260 coprocessor. Hardware traffic encryption functions are performed with a HiFn 7902 encryption chip. 2.6 Firmware Security The module is written in ANSI C. Some core cryptographic transforms are written in assembly code for better performance. The RSA Crypto-C static library is used for pub- lic key operations; it is proprietary and not available for inspection. None of the algo- rithms used in the Crypto-C library are FIPS Approved. Integrity of the firmware is ensured through three independent mechanisms. · A CRC32 checksum of both the firmware load and the independently loaded boot code check against hardware or operational errors in the handling of the firmware. · A FIPS 113 compliant Data Authentication Code is associated with every load of FIPS compliant boot code and operating firmware. Firmware with an incorrect DAC cannot be loaded into the device. · All released firmware versions have the SHA-1 residue of the firmware image pub- lished by Blue Ridge Networks. This residue can be calculated and checked both before the code is loaded on the device, and after it is loaded but before it is permit- ted to execute. 2.7 Embedded Control Program The "operating system" for the BorderGuard is a proprietary embedded system control program written specifically for the BorderGuard product line. Blue Ridge does not consider this function to be an "operating system" as it provides no capability to exe- cute code that is not integrated into the single firmware image. The control program is -6- BorderGuard 4000/3140 Security Policy not accessible to the user nor is it shared with other applications. The control program does not permit the dynamic addition and execution of code from any source. 3.0 Identification and Authentication Policy The module supports only two roles, that of crypto-officer and user. The crypto-officer has access to the console RS232 port and optionally via TELNET. The user has no access to the control inputs or status of the module. 3.1 Crypto-officer The Crypto-officer is as an individual charged with installation and maintenance of the BG4000, and the formulation and maintenance of a site Security Policy. The Crypto-officer role is the only one that can modify or inspect the state of the BG4000. Access to the device is restricted by an access password; it is typically further restricted by locating the device in a secured area. Crypto-officer functions with the BG4000 include: · Installation of the unit, and monitoring of the unit's Self Test capabilities. · Monitoring of the unit's operation. · Definition of a Forwarding Policy and Security Policy, and maintaining those Poli- cies in the face of ever-changing network requirements. 3.2 User The Users of a BG4000 are those host computers, their associated individuals, and other authenticated modules who generate network traffic to be processed by the BG4000. Since these user data sources and destinations are networked devices, Users and their hosts do not have to be co-located with the BG4000. Operation of the BG4000, and any decision as to whether the BG4000's services will be performed for a User, are completely under the control of the Crypto-officer. Users may be completely unaware of the fact that the BG4000 exists, or that it is securing data they are sending to remote locations. User authentication consists of authenticating cryptographic sessions that will contain packets arriv- ing from a remote site with other Users. This is performed with RSA public/private key pairs. A sec- ond, far weaker form of authentication consists of policies identifying Users in the interior site, and determining policy for one internal, local User versus another, based on originating IP address or other message contents. RSA Public Key authentication takes place in both directions. The BG4000 that initiates a session prepares a field consisting of a 32 bit nonce, a 128 bit MD5 message residue, and about 48 bytes of other session information. Before transmission, this field is encrypted with both its own private key and the public key of the remote BG4000. The remote unit returns the nonce and session informa- tion RSA encrypted with the public key of the originating BG4000. RSA keys of either 512 or 1024 bits in length may be selected by the Crypto-officer. -7- BorderGuard 4000/3140 Security Policy Table 1: Roles and Required Identification and Authentication Role Type of Authentica- Authentication Data tion User RSA 512 bit Public Keys 32 bit nonce + 48 bytes variable session data + MD5 hash. User RSA 1024 bit Public Keys 32 bit nonce + 48 bytes variable session data + MD5 hash. Crypto-Officer Logon Password Fixed password 3.3 Policy Definition The function of defining a site security policy for the module is described in Blue Ridge customer documentation such the BorderGuard 4000 Getting Started Guide, and the DPF Administrator's Guide. The construction of an access policy by the Crypto-officer/system administrator consists of two major steps: defining a Forwarding Policy that identifies sets of remote User site traffic and non- User traffic, then defining a cryptographic Security Policy to secure User traffic moving between sites. Forwarding Policy consists of identifying traffic as intended for delivery to a specific remote site based on its source and destination IP address, and other internal packet characteristics. Forwarding Policy also controls the disposition of traffic coming to or from locations that are not identifiably a remote site, such as general Internet traffic. To implement a Forwarding Policy, the Crypto-officer will need to identify: · the connection points at which a BorderGuard 4000 should be placed · the complement of trusted sites, and the method to identify traffic intended for each of them. · the type(s) of traffic to allow in from untrusted sites · the type(s) of traffic to block from untrusted sites · the type(s) of traffic to allow out to trusted sites · the type(s) of traffic to block to trusted sites Cryptographic Policy. For traffic to each trusted remote site, the local and remote Crypto-officers must agree on a Security Policy that meets both their needs. Security services offered by the BG4000 include: · Encryption -- prevents untrusted parties from examining the contents of traffic moving between sites. Five Approved encryption algorithms (DES, TDES, AES128, AES192, AES256) are available. The DES algorithms are included for compatibility purposes only. · Integrity Checking -- performs a keyed hash of each data packet, so that an enroute packet may not be altered by third parties, nor may they successfully intro- duce a new packet into the secured data stream. The Approved HMAC-SHA-1 is available. -8- BorderGuard 4000/3140 Security Policy · Replay Prevention -- prevents attacks caused by re-introducing a previously sent legitimate data packet into a secured data stream. The BG4000 also offers data compression services for traffic moving between secured sites. FIPS Mode. The BG4000 Cryptographic Module offers both Approved and non-Approved crypto- graphic transforms. The Crypto-officer must ensure that only Approved transforms are in use by: · Selecting one of the AES128, AES192, AES256, DES, or TDES cryptographic trans- forms. · If packet integrity checking is desired, selecting the HMAC-SHA1 algorithm. Proper selection of Approved algorithms can be confirmed through a console command ("dpf show status") which will report the number of active sessions that are using fully Approved transforms and those which are not. 4.0 Access Control Policy Access to the internals of the module is restricted to the Crypto-officer. The User may only perform encryption or decryption services and has no access to the internals of the module. Crypto-officer access control is by a password. The nature of the unit as a network appliance usually means that the device is not in a User accessi- ble location. Under most circumstances, it can be locked in a communications area only accessible to the Crypto-officer. 4.1 Access to Critical Security parameters Items the crypto-officer can control: · Generation of an RSA public/private key pair for the BG4000 device. A separate key pair may exist for both 512 and 1024 bit keys. Once the key pair is generated, the public key is available for export to other devices. The private keys cannot be inspected or exported in any form. · Definition of cryptographic network tunnels (sleeves), and the cryptographic quality of service used within the tunnel. Note however that the Crypto-officer does not have unilateral control over these definitions unless they are also the Crypto-officer for the remote unit they wish to have share in the activity. A remote unit will fail to connect and pass traffic to the local unit if the local Crypto-officer proposes a crypto- graphic policy the remote Crypto-officer does not agree with. Both need to define complementary service definitions. · Installation and exchange of RSA Public Keys for remote units. These public keys are used to authenticate the sleeve before any traffic will be sent over it. Again, installation of public keys in remote BG4000's requires the explicit cooperation of the remote unit's Crypto-officers. · Control of the Forwarding Policy within the BorderGuard, which decides what traf- fic is to be presented to the Cryptographic Module, and which virtual cryptographic connection will be used to transport a specific data item. The Crypto-officer does not have any access to: · Cryptographic traffic keys. They are automatically generated for each crypto- graphic session, and zeroized when the session is complete. They cannot be -9- BorderGuard 4000/3140 Security Policy inspected while in use, nor are there any facilities to manually introduce such keys into the unit. · RSA private keys. RSA private keys for the unit may be generated by the Crypto- officer, but they cannot be inspected during or after generation. Only the public key associated with the private key is available for export. 4.2 Key Management Keys used by the BG4000 Cryptographic Module include the following: · An RSA public/private key pair associated with the individual unit. The private key is not available to the operator, the public key is available to the crypto-officer. Only public keys can be entered or output from the module. The public/private key pair can be zeroized in both volatile and nonvolatile storage when a new key pair is gen- erated, or when the keys are cleared by a specific operator command. · Encryption traffic keys which include DES, TDES, IDEA and AES. These keys are generated through the Diffie-Hellman key agreement algorithm during session establishment and are associated with the session. The keys are zeroized immedi- ately upon session termination. These keys cannot be set manually, nor may they be inspected. · Keyed data strings used for MD5 and SHA-1 keyed hashes. These are used where a shared secret key is exchanged between sender and receiver and guards against a man-in-the-middle attack.These keys are generated through the Diffie-Hellmann key agreement algorithm during session establishment and are associated with the session. These keys are zeroized upon termination of the session. Other authentication data used by the unit consists of: · a logon password for the Crypto-officer, which may be entered when connectivity has been achieved through access to the serial port, or through a Telnet connection. The password is stored in hashed form in a data file (profile) on the BG4000's file- system. The hashing algorithm is not of cryptographic quality; however the entire filesystem is not accessible to anyone save authenticated Crypto-officers. · an optional USB "smart card" token which must be inserted into a receptacle on the front of the BorderGuard 4000 in order for the unit to successfully boot. Authentica- tion takes place in boot code, and normal smart card techniques of having the token do an MD5 hash of a specified 64 byte random string catenated with a 20 byte shared secret stored both on the token and in nonvolatile memory. If the hash and comparison fails, the unit will not boot, and the cryptographic firmware will not even be loaded into the unit. - 10 - BorderGuard 4000/3140 Security Policy Table 2: Strengths of Authentication Mechanisms Authentication Mechanism Strength of Mechanism User Session Authentication; establishment of 512 or 1024 bit RSA public/private key pairs; both a cryptographic association between two BG4000's authenticate themselves to the other. BG4000's Packet Integrity Checking FIPS 198 keyed hash is appended to each data packet; secret key material is generated via Diffie- Hellmann mechanisms during session authentica- tion. Key material is obtained through Diffie-Hell- man key exchange. Console logon by Crypto-Officer Physical access to the device, or Telnet, fol- lowed by a fixed password of at least 4 alpha- numeric characters. The password is reduced to a 32 bit value using the CRC32 algorithm, giving a net strength of (62^4). BG4000 Token Optional feature; MD5 hash of 64 byte chal- (BorderGuard 4000 only) lenge string catenated with a 20 byte shared secret. Table 3: Services Authorized for Roles Role Authorized Services User Symmetric Encryption/Decryption Asymmetric Encryption/Decryption (session authen- tication) MACing Keyed Hashing (packet authentication) Crypto-officer Public/private key generation. Export and import of public keys Cryptographic TOS for tunnels Forwarding policy -- Direction of IP packets through designated tunnels. Module Configuration. Key Management. Module Initialization. Discretionary Self Test. Set/Change Crypto-Officer password. Zeroize keys. Show Status. - 11 - BorderGuard 4000/3140 Security Policy Table 4: Access to Critical Security Parameters CSP Type User Access Crypto-officer Access RSA private key none replacement or zeroization RSA public key none inspection, export, replace- ment, zeroization of internal public key; import, inspec- tion, and modification of external public keys Traffic Encryption Keys none none Keyed Hash (SHA-1) Keys none none Console password none modification USB token authentication data none Usage through key insertion. The authentication data could be destroyed with third party tools, but not inspected 4.3 Key Protection Private and secret keys are protected inside the module. No command, public or hid- den, permits the display or export of these keys. In addition, the private key is stored in Triple-DES encrypted form, using a fixed Triple-DES 192 bit key generated by hash- ing the chassis serial number and various constants located throughout the firmware. Since this Triple-DES key is fixed for any given chassis, from the vantage of FIPS 140- 2 it is logically equivalent to plaintext key storage. Secret keys are never stored or archived. During the session, the secret key is located in SDRAM data structures that are not accessible to any user or crypto-officer. All secret keys and key schedules are zeroized as soon as their session is terminated. Only the RSA public key is distributed. Public keys are stored in plaintext form. 4.4 Key Destruction The RSA public/private key pairs in the BG4000 Cryptographic Module are stored in non-volatile memory. They are zeroized either through an explicit console command, or when the Crypto-officer directs that a new key pair be generated to supplant the old one. Session keys and key schedules are destroyed (zeroized) when the cryptographic session is termi- nated, or when the unit is powered off. The console password may be modified, but it cannot be removed. Powering off the unit will destroy all session keys. The USB token contents are generated at the factory and are never modified. There is no mechanism in the BG4000 to destroy the token contents. - 12 - BorderGuard 4000/3140 Security Policy 4.5 Random Number Generation The BG4000 Cryptographic Module uses both a non-deterministic and deterministic random bit generation scheme. A hardware chip, the HiFn 7902, is used to generate a nondeterministic random bit sequence. This random sequence is continuously XOR-ed with random 40 nanosecond resolution packet arrival times to produce a changing 20 byte seed value. This seed is then the basis of the deterministic RNG, an implementa- tion of the BSAFE 5.2.1 library. The deterministic RNG uses a SHA-1 hash of the seed for input. The Crypto-C deterministic random number generator is not an Approved RNG. The RNG is constantly conditionally tested for failure to a constant value. 4.6 Cryptographic Algorithms Table 5: BG4000 Cryptographic Module -- Algorithms FIPS 140-2 NIST Algorithm Mode Approved Certificate Usage Test Algorithm Number AES128 Firmware Yes 116 Encrypt/decrypt KAT FIPS 197 traffic AES192 Firmware Yes 116 Encrypt/decrypt KAT FIPS 197 traffic AES256 Firmware Yes 116 Encrypt/decrypt KAT FIPS 197 traffic DES Hardware Yes 243 Encrypt/decrypt KAT (HiFn 7902) FIPS 46-3 traffic DES Firmware Yes 119 Encrypt/decrypt traffic; KAT FIPS 46-3 backup for DES hard- ware encryption TDES Hardware Yes 227 Encrypt/decrypt KAT (HiFn 7902) FIPS 46-3 traffic TDES Firmware Yes 228 Encrypt/decrypt traffic; KAT FIPS 46-3 backup for TDES hard- ware encryption IDEA Firmware No none Encrypt/decrypt KAT traffic HMAC-SHA1 Firmware Yes 203 Integrity check KAT FIPS 198 traffic HMAC-MD5 Firmware No none Integrity check KAT traffic MD5 Hardware No none Integrity check KAT (HiFn 7902) traffic - 13 - BorderGuard 4000/3140 Security Policy FIPS 140-2 NIST Algorithm Mode Approved Certificate Usage Test Algorithm Number MD5 Firmware No none Integrity check KAT traffic; backup for MD5 hardware SHA-1 Hardware Yes 203 Integrity check KAT (HiFn 7902) FIPS 180-1 traffic SHA-1 Firmware Yes 49 Integrity check KAT FIPS 180-1 (vendor traffic; backup for affirmed) SHA hardware Diffie-Hell- Firmware no none Session key Pairs test mann (Bsafe 5.2.1) negotiation RSA Firmware no none Session Pairs test (Bsafe 5.2.1) Authentication FIPS 113 Firmware yes 119 Validates authenticity none; DAC (vendor of firmware image firmware affirmed) load fails if error USB Token Firmware + no none Optionally determine if none; Validation "smart card" a unique USB token is firmware logic on token inserted in the unit load fails if error The BorderGuard contains both Approved and non-Approved cryptographic algorithms. Crypto- Officers have two mechanisms to ensure whether Approved algorithms are being used: · By examining the definitions of cryptographic tunnels, and ensuring that only Approved algorithms as specified in Table 5 are specified. · By entering the dpf show status console command, which will print a summary of the number of cryptographic sessions operating in Approved mode, and the number which are in non-Approved mode. 5.0 Physical Security Policy The module is a multi-chip standalone embodiment, housed within a 1-unit high sheet metal chassis, protected by tamper evident seals and four tamper proof screws. The placement of the screws and tape on the chassis is shown in Figure 3 on page 15. The tamper resistant screws consist of a five pointed star receptacle with a center pin, and require a special tool licensed by the manufacturer to remove. The tamper evident tape shatters as it is removed. There are no user or administrator serviceable or configurable items inside the chassis. There is no reason for the customer to open the chassis, which must be returned to the factory should mainte- nance be required. The tamper evident seal must be inspected periodically to detect tampering. The module conforms with the EMI/EMC requirements in FCC Part 15, Subpart J, Class A. - 14 - BorderGuard 4000/3140 Security Policy Physical security may also be enhanced with the optional USB token that is keyed to a particular BG4000. Whenever the unit is powered on, boot code will not proceed to initialize the unit unless a cryptographic challenge between the BG4000 and USB token succeeds. Thus if the USB token key is removed and kept in a safe location, the BG4000 may not be placed into any type of service. Table 6: Inspection/Testing of Physical Security Mechanisms Physical Security Recommended Inspection/Test Mechanism Frequency of Guidance Detail Inspection/Test Tamper evident tape Variable; dependent of secu- Inspect tape for breaks; the rity of area in which the tape cannot be removed with- BG4000 is located out fragmenting into pieces 6.0 Mitigation of Other Attacks 6.1 Replay Prevention The BG4000 Cryptographic Module can also optionally institute replay protection by insuring that any packet is received only once. The module maintains a record of recently received sequence numbers. If the incoming packet has a sequence number that has already been recorded, the module will drop the packet and raise an alarm. FIGURE 3. Placement of Physical Security Safeguards Top Bottom Tamper resistant screws Tamper evident tape Back - 15 - BorderGuard 4000/3140 Security Policy 6.2 Denial of Service Attacks The BG4000 Cryptographic Module recognizes that service to legitimate users may be denied through illicit session establishment attempts that are recognized by the attacker to fail. Should a session connect request be received that does not result in a successful connection, the IP address from which the request originated will be placed on an "unreachable" list for an exponen- tially increasing period of time, and further requests from that source will be ignored. Similarly, if the BG4000 originates a connection that fails for some reason (most likely because the partner BG4000 is unreachable), it will defer connects to that device for an exponentially increasing period of time to avoid "thrashing" the authentication mechanism. 6.3 Tamper resistant screws In addition to the tamper evident tape, the BorderGuard 4000 chassis is secured with four tamper resistant screws. These screw heads have a five pointed star socket with a center post, and the tool to remove them is only available under license from the man- ufacturer. 7.0 Self-Tests 7.1 Mandatory tests Mandatory tests are performed at boot time, when the BG4000 Cryptographic Module is in the initialization state. These include: · Testing the hardware cryptographic processor to check its register and data trans- fer operation. · Testing the Approved DES and TDES hardware based encryption and decryption algorithms with a known answer test. · Testing the firmware implemented AES-128, AES-192, AES-256, DES, and Triple- DES encryption algorithms with a Known Answer Test. · Testing the Approved SHA-1 hardware based hashing algorithm with Known Answer Tests. · Testing the Approved HMAC-SHA-1 and SHA-1 firmware based hashing algorithm with Known Answer Tests. · Testing the random number generator using the Ones, Poker, Runs and Long Runs tests as previously specified in FIPS 140-2 section 4.9.1. · Testing the non-Approved MD5 hardware based hashes with a known answer test. · Testing the non-Approved HMAC-MD5, and MD5 firmware based hashes with a known answer test. 7.2 Conditional Tests The BG4000 Cryptographic Module performs several Conditional tests during opera- tion · The output of the Random Number Generator is continuously checked to ensure that it is not returning a constant value. - 16 - BorderGuard 4000/3140 Security Policy · The RSA public/private key pair is used for all four combinations of public and pri- vate key encryption and decryption (public key encrypt and decrypt, private key encrypt and decrypt) during the normal authentication procedure with other BG4000's, which will fail if the key pair is not pairwise consistent. 7.3 Optional self-tests Optional self tests are available to the crypto-officer for discretionary module testing and include all of the KATs above. All Mandatory tests detailed above may be run at any time though console commands entered by the Crypto-officer. Additional optional tests exist for: · Pairwise consistency of Diffie-Hellman operation. · KAT's for the non-Approved IDEA encryption algorithm.. 7.4 Failure of self-test In the event of a self test failure of the cryptographic hardware, or if an error is detected during continuing operation of the cryptographic hardware, the BG4000 Cryptographic Module will disable the hardware processor and proceed to perform all cryptographic transforms using firmware. Errors encountered are shown on both the front panel LCD display and any attached serial console. The BG4000 has no specific provisions for failure of the firmware algorithms, as this indicates either an internal failure of the controlling MPC8260 processor, or run-time corruption of the code or SDRAM memory access. In these circumstances, the BG4000 will cease useful program execu- tion and pass no further data of any type. - 17 - BorderGuard 4000/3140 Security Policy Appendix A Glossary of Acronyms AES Advanced Encryption Standard. An Approved algorithm defined in FIPS 198, supporting 128, 192 and 256 bit keys. ANSI American National Standards Institute. In the context of this document, ANSI is responsible for the definition of the C programming language used for most of the BG4000/ 3140 firmware. CRC32 32 bit Cyclic Redundancy Check. A common mechanism to detect data corruption (but not cryptographic attack) in a stream of data. CSP Critical Security Parameter. A value such as a crypto- graphic key, whose disclosure or modification might com- promise the security of the system. DES Data Encryption Standard. A widely used encryption algo- rithm defined in FIPS 46-3. DPF Data Privacy Facility. The Blue Ridge Networks trade name for its cryptographic function, and the designation for the Cryptographic Module. EMC Electromagnetic Compatibility. The degree with which a device will tolerate EMI from nearby devices. EMI Electromagnetic Interference. A measure of the degree to which radio frequencies emitted by a device might inter- fere with the operation of other nearby appliances. HMAC A keyed message authentication algorithm, where the message contents and a secret key are cryptographically hashed so that an attacker cannot produce a message deemed genuine to the receiver without knowledge of the key. IDEA International Data Encryption Algorithm. A non- Approved cryptographic algorithm in moderately wide use. IP Internet Protocol, as defined in RFC 791. KAT Known Answer Test. The process of presenting fixed inputs to a cryptographic algorithm, and comparing the compute result with a published, expected result. MD5 Message Digest (version 5). A non-Approved cryptographic hashing algorithm. RNG Random Number Generator. - 17 - BorderGuard 4000/3140 Security Policy RSA 1. RSA Data Security Inc., the supplier of the crypto- graphic library used for authentication, key exchange, and random number generation in the BG4000/3140. 2. Rivest-Shamir-Adleman public/private key encryption algorithms. The basis of User authentication on the BG4000/3140. SDRAM Synchronous Dynamic Random Access Memory. A com- mon electronic technology for high capacity, moderate speed random access memory. SHA-1 Secure Hash Algorithm (version 1). An Approved crypto- graphic hashing algorithm. Triple-DES A cryptographic block cipher using 112 or 168 bit keys. An Approved algorithm defined in FIPS 46-3. TOS Type of Service. In the context of this document it specifi- cally refers to the 4 bit Type of Service field in an Internet Protocol packet header that directs network equipment to optimize transmission for throughput, performance, etc. USB Universal Serial Bus. A common standard for the connec- tion of low and medium speed devices to personal comput- ers. The BG4000 takes advantage of USB based "smart card" tokens to unlock suitably configured BG4000 devices. - 18 -