BitArmor Secure Cryptographic Engine Version 1.2 Security Policy v 1.0 BitArmor Systems, Inc Copyright ©2009 BitArmor Systems, Inc. 401 Liberty Avenue, Suite 1900 All rights reserved. BitArmor, BitArmor Systems, and Smart Tag technology are trademarks of Pittsburgh, PA 15222 BitArmor Systems, Inc. Phone: 412-682-2200 www.bitarmor.com Page 1 of 16 FIPS 140-2 Security Policy I. Introduction .............................................................................................................................................. 4 A. Overview ........................................................................................................................................... 4 B. Purpose ............................................................................................................................................. 4 C. References ........................................................................................................................................ 4 D. Conventions ...................................................................................................................................... 4 E. Disclosure .......................................................................................................................................... 4 II. Cryptographic Module Specification......................................................................................................... 5 A. Description ........................................................................................................................................ 5 B. Cryptographic Boundary ................................................................................................................... 5 C. Modes of Operation .......................................................................................................................... 7 D. FIPS-Approved Functionality ............................................................................................................. 7 E. Non-FIPS Functionality ...................................................................................................................... 8 F. Module Ports and Interfaces ............................................................................................................ 8 G. Roles, Services and Authentication................................................................................................... 9 TABLE 5: SERVICES AND ACCESS CONTROL .............................................................................................. 10 TABLE 6: DESCRIPTION OF SERVICES ...................................................................................................... 10 H. Self-Tests ......................................................................................................................................... 10 BASCE MODULE INTEGRITY VERIFICATION ............................................................................................. 11 BASCE KNOWN ANSWER TESTS (KATS) ................................................................................................ 11 TABLE 7: KNOWN ANSWER TESTS ................................................................................................................. 12 BASCE CONDITIONAL TESTING ............................................................................................................. 12 TABLE 8: CONDITIONAL TESTING ................................................................................................................... 12 I. Physical Security.............................................................................................................................. 12 J. Operational Environment ............................................................................................................... 12 K. Cryptographic Key Management .................................................................................................... 12 TABLE 9: CRYPTOGRAPHIC KEYS AND CSPS ........................................................................................... 13 CSP OUTPUT CONTROLS ..................................................................................................................... 13 L. Design Assurance ............................................................................................................................ 14 M. Mitigation of Other Attacks ........................................................................................................ 14 Page 2 of 16 III. FIPS 140-2 Compliant Operation............................................................................................................ 14 A. Crypto-Officer Guidance ................................................................................................................. 14 INSTALLATION AND INITIALIZATION ........................................................................................................ 14 ZEROIZATION ..................................................................................................................................... 15 MANAGEMENT .................................................................................................................................. 16 B. User Guidance ................................................................................................................................. 16 Page 3 of 16 I. Introduction A. Overview BitArmor offers breakthrough data protection software that protects data wherever it goes. Because it combines persistent file encryption with full disk encryption, BitArmor gives customers a single integrated solution for protecting data at all of its most vulnerable points, like on laptops, on USB drives, in e-mail attachments. BitArmor software helps customers precisely control access to sensitive data so they can achieve regulatory compliance, reduce the liability of publicly disclosing data breaches, and protect valuable intellectual property that is shared inside and outside of their enterprise. Leaders in the Healthcare, Retail, Education, and Legal industries — among others — have chosen BitArmor’s easy-to-manage, cost-effective data protection. B. Purpose This document is the non-proprietary cryptographic module security policy for the BitArmor Secure Cryptographic Engine from BitArmor Systems, Inc. It serves as a reference description for BitArmor’s cryptographic module and its compliance to the FIPS 140-2 security standard. This document was prepared as part of the FIPS 140-2 Security Level 1 validation of BASCE. C. References BitArmor Systems, Inc.’s website (www.bitarmor.com) provides detailed information on the company and its DataControlTM security products that utilize proprietary SmartTag™ technology and are covered by BitArmor’s No-Breach GuaranteeTM. The Federal Information Processing Standards Publication 140-2 (FIPS 140-2), Security Requirements for Cryptographic Modules, specifies the U.S. and Canadian governments’ requirements for cryptographic modules. Complete details on the FIPS 140-2 Cryptographic Module Validation Program (CMVP) can be found at csrc.nist.gov/groups/STM/index.html. D. Conventions Hereafter, this document refers to the BitArmor Secure Cryptographic Engine as either BASCE, “the cryptographic module”, or simply, “the module”. E. Disclosure This non-proprietary security policy may be reproduced and distributed intact including the ©2009 BitArmor Systems, Inc. copyright notice depicted on page 1 of this document and shown here: Copyright ©2009 BitArmor Systems, Inc. All rights reserved. BitArmor, BitArmor Systems, and Smart Tag technology are trademarks of BitArmor Systems, Inc. Page 4 of 16 II. Cryptographic Module Specification A. Description BASCE Version 1.2 is a software module that provides advanced cryptographic functionality to BitArmor DataControl software products, including strong encryption, secure integrity and authentication, and random number generation. BASCE Version 1.2 consists of two dynamically linked software libraries: FIPSModule.dll, BA_crypto.dll on MS Windows, and libcryptmod.so, libcrypto.so on SUSE Linux Enterprise Server. The cryptographic module Application Program Interface (API) is provided in full by FIPSModule.dll/libcryptmod.so, which in turn loads and uses BA_Crypto.dll/libcrypto.so in a private manner to provide FIPS-Approved cryptographic functionality to BitArmor DataControl client applications. BASCE Version 1.2 meets the overall requirements of Level 1 security of the FIPS 140-2 standard. Individual security sections of BASCE Version 1.2 are validated at the FIPS 140-2 security levels shown in Table 1 below. FIPS 140-2 Security Section Security Level Cryptographic Module Specification 3 Module Ports and Interfaces 1 Roles, Services and Authentication 1 Finite State Model 1 Physical Security Not Applicable Operational Environment 1 Cryptographic Key Management 1 EMI/EMC 1 Self-Tests 1 Design Assurance 1 Mitigation of Other Attacks Not Applicable TABLE 1: BASCE SECURITY LEVEL VALIDATION PER FIPS 140-2 SECTION B. Cryptographic Boundary For FIPS 140-2 purposes, BASCE Version 1.2 (subsequently referred to as just BASCE) is classified as a multi-chip standalone module. BASCE’s logical cryptographic boundary is the software library file and its public API. BASCE comprises two such files: FIPSModule.dll and BA_crypto.dll for Microsoft Windows operating systems and libcryptmod.so and libcrypto.so for the SUSE Linux Enterprise Server operating system. Page 5 of 16 BASCE’s physical boundary is the general purpose computer on which the module and client applications run. General purpose computers typically include these basic hardware components: Intel x86 processor or equivalent (CPU) Video controller Memory (RAM) Serial & parallel ports Power supply Hard disk, CD/DVD-ROM, floppy disk Keyboard, mouse, video, Universal Serial Bus (USB) and Ethernet network interfaces FIGURE 1: PHYSICAL & LOGICAL CRYPTOGRAPHIC BOUNDARIES The physical and logical cryptographic boundaries of BASCE are shown in Figure 1. The physical computer enclosure contains general purpose computer hardware and is where BASCE and its client-application runs, thus it forms the physical cryptographic boundary of BASCE. The logical cryptographic boundary is the BASCE API and its software components consisting of two dynamic-link library files whose names are operating system dependent. External devices that interface to the general purpose computer (e.g., video, keyboard, mouse, etc.) are outside BASCE’s physical cryptographic boundary. FIPSModule.dll (MS Windows) and libcryptmod.so (SUSE Linux Enterprise Server) implement BASCE’s API. FIPSModule.dll utilizes BA_CryptoLib.dll (and libcryptmod.so utilizes libcrypto.so) to provide cryptographic functionality, accessing it through private routines only. BASCE Page 6 of 16 interacts only with the client-application based process that loads it; the module makes no network connections, spawns no new threads, and performs no file output or interprocess communication. In addition, the module does not store any critical security parameter (CSP) internally — all CSPs are passed by the client-application using references only. Finally, BASCE is implemented entirely in software therefore physical security is provided solely by the host platform. Accordingly, in conjunction with FIPS 140-2 Security Level 1 requirements, BASCE is not subject to the physical security requirements of the standard. For the purpose of FIPS 140-2 validation, BASCE was tested on Microsoft Windows XP- Professional SP3 (32-bit) and SUSE Linux Enterprise Server 10 (32-bit) operating systems. C. Modes of Operation BASCE will operate in the following two modes of operation: 1. Non-Approved Mode 2. FIPS Mode BASCE operates in Non-Approved Mode by default upon loading and initialization by a client- application. In order to operate in FIPS Mode, the application must call the CM_setFIPSMode routine, which performs module integrity and known-answer testing. If all tests are successful the module transitions to FIPS Mode, otherwise it transitions to a failed operational state in which no cryptographic functionality is available. FIPS-approved and non-FIPS approved cryptographic algorithms can be run in the Non-Approved Mode. The CM_setFIPSMode routine takes an integer input parameter called “mode”, which it uses to establish BASCE’s mode of operation. “Mode” must be set to ‘1’ to operate BASCE in FIPS Mode. Once BASCE establishes FIPS Mode operation, its mode cannot be changed to Non- Approved Mode. Note: All keys used while running BASCE in Non-Approved Mode are not to be used during subsequent operation of BASCE in FIPS Mode. Conversely, all keys used while running in FIPS Mode must not be used in Non-Approved Mode. BASCE provides zeroization routines for all of its cryptographic data types, which should be utilized to zeroize all client-application CSPs prior to transitioning to FIPS Mode, or out of FIPS Mode. Refer to section G. Roles, Services and Authentication below for details. D. FIPS-Approved Functionality BASCE contains the following FIPS-approved cryptographic functionality. Algorithm Function FIPS Std CAVP Certificate# AES (ECB, CBC and CTR modes) Symmetric Cipher FIPS PUB 197 1101 Page 7 of 16 TDES (ECB, CBC and CTR modes) Symmetric Cipher NIST SP800-67 802 SHA-1, SHA-256, SHA-384, SHA-512 Message Digest FIPS PUB 180-3 1024 HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, Message FIPS PUB 198-1 614 HMAC-SHA-512 Authentication ANSI X9.31 Appendix A.2.4 PRNG AES-128, AES-256 Deterministic RNG FIPS PUB 186-2 613 TABLE 2: FIPS APPROVED FUNCTIONALITY These functions are made available by BASCE in both FIPS and Non-Approved Modes of operation. E. Non-FIPS Functionality BASCE contains the following non-FIPS-approved cryptographic functionality. Algorithm Function DES (ECB, CBC, and CTR modes) Symmetric Cipher MD5 Message Digest HMAC-MD5 Message Authentication TABLE 3: NON-FIPS APPROVED FUNCTIONALITY These functions are made available by BASCE only when operating in Non-Approved Mode. They are physically blocked by the module while in FIPS Mode and result in an error indicating they are not available in FIPS Mode, when called. F. Module Ports and Interfaces The physical ports of BASCE are those of the general purpose computer system on which it runs, including keyboard, mouse, network, hard disk drive, CD-ROM drive, video, USB and power. BASCE has no direct physical controls, status indicators or electrical characteristics that impact its operation. Logical controls and status indicators take the form of input/output parameters of the module’s API. BASCE’s API is its logical interface and the sole means by which client applications communicate with it. All information flows through four logically distinct interfaces as required by FIPS 140-2: data input, data output, control input, and status output. Although these interfaces share the same physical port, BASCE’s API preserves the interface type semantic using explicit input, output, control, and status parameters. These interfaces are defined in Table 4 below. Logical Module Interface Physical Port Interface API function parameters that contain data values or Keyboard, hard disk, mouse, CD- Data Input references to data structures, which are used as input ROM, floppy disk, and USB/ to a module function parallel/serial/network ports Page 8 of 16 API function parameters that contain data values that Video monitor, hard disk, floppy disk, Data Output are, or references to data structures that refer to, and USB/parallel/serial/ network output from a module function ports Keyboard, hard disk, mouse, CD- API function calls that initialize and modify the control Control Input ROM, floppy disk, and USB/ state and operational mode of the module parallel/serial/network ports Video monitor, hard disk, floppy disk, Status Output API function return values and USB/parallel/serial/ network ports Not applicable Power supply Power TABLE 4: PORTS AND INTERFACES G. Roles, Services and Authentication BASCE supports both the Crypto-Officer and User roles for cryptographic module operation as required by FIPS 140-2. The operator assumes either of the roles based on the operations being performed; BASCE does not provide authentication and does not support concurrent operators. BASCE supports the following services and access control. Role Service CSP Access ADMINISTRATIVE SERVICES Install None - Crypto-Officer Uninstall None - Initialize None - Show Version None - Show Mode None - Crypto-Officer Module Integrity or Set FIPS Mode Execute HMAC-SHA-256 Key User Module Integrity Run Self-Tests Execute HMAC-SHA-256 Key AES, TDES, HMAC-SHA-*Key, Zeroize Write PRNG Seed or Seed Key CRYPTOGRAPHIC SERVICES AES, TDES Symmetric Encryption/Decryption Execute Symmetric Key Crypto-Officer Message Digest (SHA-1, or none Execute SHA-256, SHA-384, SHA-512) User Keyed Hash (HMAC-SHA-1, HMAC-SHA-* Key Execute -SHA-256, -SHA-384, -SHA-512) Page 9 of 16 Pseudo Random Number Generation Write, Seed, Seed Key ANSI X9.31 Appendix A.2.4 PRNG Execute (AES-128/-256) TABLE 5: SERVICES AND ACCESS CONTROL Note that only the Crypto-Officer can install and uninstall BASCE but all other services can be performed by either Crypto-Officer or User role. The administrative services from Table 5 are described in more detail in Table 6 below. Service Description API Function Input Output Initialize BASCE to Non- Initialize Approved Mode; must be run None Integer indicating Success or Failure CM_init before any other function Show Obtain BASCE’s version Major, Minor, Patch, Build number CM_getFIPSModule None Version Version number as 32-bit unsigned integer Set FIPS Set BASCE operation mode to Mode Integer indicating Success or Failure CM_setFIPSMode Mode FIPS Mode Show Obtain BASCE’s current Integer indicating FIPS or Non- None CM_getFIPSMode Mode operating mode Approved Mode Execute all BASCE known answer self-tests and module Success or Failure; Run integrity test, blocking all None In the event of Failure, transition CM_runSelfTests Self-Tests security function output BASCE to the error/failed state during operation Zeroize BASCE’s HMAC-SHA-256 Zeroize BASCE’s integrity key None CM_zeroize integrity key Zeroize and free the client- Cipher Zeroize an AES, TDES key application’s memory structure CM_releaseCipher Handle associated with a symmetric cipher Zeroize and free the client- Zeroize a SHA Hash application’s memory structure CM_releaseHash message digest Handle associated with a message digest Zeroize Zeroize and free the client- PRNG application’s memory structure Zeroize a PRNG Seed and Handle associated with the module’s PRNG. CM_releasePRNG Seed key and Flag If Flag is true, zeroize and release the AES 128/256 bit key as well Zeroize and free the client- HMAC key Zeroize an HMAC key application’s memory associated CM_releaseHMAC handle with an HMAC key TABLE 6: DESCRIPTION OF SERVICES H. Self-Tests As mentioned in the services above, BASCE employs self-tests to ensure the module’s integrity is intact and that it’s functioning properly. Self-tests are performed when the Crypto-Officer Page 10 of 16 requests that the module operate in FIPS Mode, or on demand while BASCE is in FIPS Mode by invoking the Run Self-Tests service. In addition, the FIPS 140-2 Continuous Random Number Generator Test is performed while the module operates in FIPS Mode. BASCE’s self-tests include module integrity verification and cryptographic service known answer tests. During execution of self-tests, BASCE blocks access to all cryptographic services. If any self-test fails, the module is transitioned to an error state and subsequent calls will return an error code indicating this condition. Such errors can only be recovered by reloading BASCE by restarting the application, reinstalling BASCE, or returning it BitArmor for analysis and repair if the problem persists. BASCE Module Integrity Verification Module integrity verification is a self-test that is performed by checking a build (compile) time HMAC-SHA-256 digest against the runtime executables. If the pre-computed value matches the runtime-computed value, then the test succeeds otherwise BASCE transitions to the irrecoverable error state described above. BASCE Known Answer Tests (KATs) Known answer tests are tests for which a set of cryptographic (question, answer) pairs are stored in the cryptographic module and utilized by self-tests for comparison of runtime performance with known results. If any KAT self-test fails, BASCE transitions to the irrecoverable error state. The following table contains self-tests that are incorporated into BASCE. CIPHER FUNCTION KAT SELF-TESTS ECB-128, -192, -256 Encrypt AES & CBC-128, -192, -256 Decrypt CTR-128, -256 Encrypt ECB-Key Option 2 TDES & CBC-Key Option 2 Decrypt SECURE HASH FUNCTION KAT SELF-TESTS SHA1 Compute 20-byte message digest SHA-256 Compute 32-byte message digest SHA-384 Compute 48-byte message digest SHA-512 Compute 64-byte message digest HMAC FUNCTION KAT SELF-TESTS HMAC-SHA-1 Compute 20-byte Keyed MAC HMAC-SHA-256 Compute 32-byte Keyed MAC HMAC-SHA-384 Compute 48-byte Keyed MAC Page 11 of 16 HMAC-SHA-512 Compute 64-byte Keyed MAC PRNG FUNCTION KAT SELF-TESTS AES-ECB-128 Compute 16-byte random number AES-ECB-256 Compute 16-byte random number MODULE INTEGRITY VERIFICATION SELF-TEST Compute run-time HMAC and compare with HMAC-SHA-256 build-time HMAC TABLE 7: KNOWN ANSWER TESTS BASCE Conditional Testing Conditional testing involves comparison of successively-generated random number values at runtime to ensure a collision does not occur. This testing is done on a continuous basis while the module operates in FIPS Mode and is referred to as the Continuous Random Number Generator Test by FIPS 140-2. This means that every time a random number is generated, it is compared with the previously generated value for a collision. If a collision ever occurs during module use, BASCE transitions to the error state in the same manner as it does if a self-test fails. CONDITIONAL TESTING ANSI X9.31 with AES-128/-256 Continuous Random Number Generator Test PRNG TABLE 8: CONDITIONAL TESTING I. Physical Security BASCE is a software-only cryptographic module and therefore FIPS 140-2 physical security requirements do not apply. J. Operational Environment As a dynamically-linked library, BASCE extends the functionality of the client-application that links/loads it. Therefore the user/operator of BASCE is defined to be its client-application for FIPS 140-2 purposes. This is relevant to the FIPS 140-2 Security Level 1 requirement that cryptographic modules must operate in a single-user mode, operational environment. Since BASCE is a software library, there is only one application that accesses it and nothing further has to be done at the operating system level to meet the FIPS 140-2 requirement. K. Cryptographic Key Management BASCE does not support long term key storage and all cryptographic key input to BASCE is through references to client-application memory structures. Any use of cryptographic keys that requires temporary storage within the module uses local function variables that are de-allocated at function termination. Page 12 of 16 BASCE uses cryptographic keys for symmetric cipher encrypt/decrypt functions AES and TDES, generating HMAC-SHA-1/-256/-384/-512, and as a seed key for its PRNG. Cryptographic keys can be encrypted using AES-128, AES-192, AES-256, or TDES and they can be zeroized by overwriting their memory with zeros using the BASCE API. If the client-application imports or exports keys outside the physical cryptographic boundary, it must use a FIPS Approved encryption method and import or export them in encrypted form. Cryptographic keys are stored in memory until they are zeroized using the API. The keys and CSPs that BASCE uses are listed in Table 9 below. Size in Module Module Cryptographic Key/CSP Source Zeroization Function Bits Input Output BASCE or PRNG Seed 128 Client- Plaintext Plaintext CM_releasePRNG Application 128 or PRNG Seed Key Plaintext - CM_releasePRNG 256 Client- 128, 192 AES Key Plaintext - CM_releaseCipher Application or 256 TDES Keys (option 2) 128 Plaintext - CM_releaseCipher HMAC-SHA-256 256 BASCE - - CM_zeroize Module Integrity Key Client- HMAC Key Any Plaintext - CM_releaseHMAC Application TABLE 9: CRYPTOGRAPHIC KEYS AND CSPS CSP Output Controls Note, that as required by FIPS 140-2, two independent, internal actions are required in order for the module to output any CSP. The PRNG Seed is the only CSP that may be output by BASCE and there are two routines that can output it – CM_initPRNG and CM_getPRNGRandom. During initialization of the PRNG data structure, CM_initPRNG will generate and output a PRNG seed if one is not input (i.e., generated and supplied by the client-application). Subsequent random number generation requires re-computing and outputting the PRNG seed via CM_getPRNGRandom. Output of the PRNG seed is controlled by two flags – a global module flag and an input parameter flag for each function above. In order for a function to output the PRNG seed, both flags must be set to ‘TRUE’; otherwise the function will fail with an error indicating that CSP output was blocked. The two independent, internal actions are: Page 13 of 16 1. First, the client-application must indicate that PRNG CSP output is required during module initialization by setting CM_init’s Boolean input parameter “outputCSP” to ‘TRUE’. This action sets the global module flag to ‘TRUE’. 2. Second, when the client-application invokes PRNG initialization and random number generation services, it must again indicate that CSP output is requested through the corresponding function’s input parameter “outputCSP”, setting it to ‘TRUE’ as well. Note that in cases where the PRNG seed is initially generated by the client-application, CSP output controls are still required in order to obtain the updated seed values computed by the module during random number generation. Also note that if a PRNG seed is not supplied by the client-application initially, one will be generated via CryptGenRandom on Windows operating systems and /dev/random on SUSE Linux. L. Design Assurance BitArmor Systems utilizes Perforce Server (v2006.2) for configuration management of product source code and documentation. Perforce supports authentication, access control, and logging. Refer to www.perforce.com for more information. M. Mitigation of Other Attacks BASCE does not provide any security mechanisms in addition to those required by FIPS 140-2 security requirements for cryptographic modules. III. FIPS 140-2 Compliant Operation A. Crypto-Officer Guidance Installation and Initialization BASCE is a component of the BitArmor DataControl security product and is not an end-user product itself. The software libraries that make it up are installed and uninstalled as part of a larger product installation procedure that is documented in the product installation guide. Upon loading by the client-application, BASCE must be initialized by calling CM_init before it can be used. This routine initializes BASCE’s control structures and establishes a Non-Approved mode of operation. BitArmor DataControl applications specify the mode of operation at run-time by calling CM_setFIPSMode, the Set FIPS Mode service, and they determine the current mode of operation by calling CM_getFIPSMode, the Show Mode service. Specifically, an application calls CM_setFIPSMode using the CM_FIPS_LEVEL1 value as an input argument in order to establish FIPS Mode. This produces a result status output of success or failure: Page 14 of 16 // Status indicator variable int status = CM_FAILURE; // Initialize the module for CSP output and set FIPS Mode if( (status = CM_init(TRUE)) == CM_SUCCESS ) { if( (status = CM_setFIPSMode(CM_FIPS_LEVEL1)) == CM_SUCCESS ) { // Operating in FIPS Mode… } else { // Could not establish FIPS Mode… } } //end Additionally, an application can confirm BASCE’s operating mode with the Show Mode service: // Determine the module’s mode of operation If( (status = CM_getFIPSMode()) == CM_FIPS_LEVEL1 ) { //FIPS Mode… } else { //Non-Approved Mode… } //end Zeroization BASCE’s API provides zeroization routines that BitArmor DataControl applications use to zeroize their in-memory CSPs (recall that BASCE stores no CSPs internally). It is recommended that client applications zeroize all CSPs prior to program termination and immediately prior to a transition from Non-Approved to FIPS Mode operation if any CSP has been used in Non- Approved Mode. (Note that BASCE does not allow transitions from FIPS Mode to Non-Approved Mode.) Each cryptographic security function of BASCE has an associated data type that the client- application must instantiate and use with BASCE’s API. Client applications pass references to data type instances in their BASCE function calls for initialization/allocation, subsequent use of the available cryptographic functionality, zeroization and de-allocation. BASCE initializes them by allocating the appropriate amount of memory and initial values based on the cryptographic function type, mode, key length, etc. The client-application then assigns data values and performs further operations in a similar manner until it finishes with a particular cryptographic function. When the client-application deems a CSP no longer necessary, it should zeroize and de-allocate the memory associated with it using the appropriate BASCE zeroization function call as described in Table 6 above. (Zeroization can be invoked by Crypto-Officer or User role.) Note that zeroizing the module integrity key (via CM_zeroize) will prevent a client-application from subsequently setting FIPS Mode. This action zeroizes the HMAC-SHA-256 key used by BASCE for Module Integrity Verification in memory only. Page 15 of 16 Management The Crypto-Officer is not required to perform any maintenance or module management after it is installed. All module management is performed at the application level. B. User Guidance BitArmor DataControl applications utilize BASCE to provide FIPS-approved cryptographic functionality to their end-users. BitArmor DataContol applications are programmed to utilize BASCE’s services in a manner that is consistent and correct according to BASCE’s detailed design and API specifications. End users of BitArmor DataControl do not need to manage, or service BASCE. End users interact with the application and do not interface directly with BASCE. Page 16 of 16