Kanguru Solutions™ KDH3000-CM Security Policy Document KDH3000-CM FIPS 140-2 Non-Proprietary Security Policy Document Revision: 1.0 H.W. Version: 1.0 F.W. Version: V01.04.0000.0000 (Kanguru Solutions Copyright 2014 - This document may be reproduced in its entirety without revision) Page 1 of 15 Kanguru Solutions™ KDH3000-CM Security Policy Document Revision History Author(s) Version Updates Nate Cote, 1.0 Initial public release. Kanguru Solutions Page 2 of 15 Kanguru Solutions™ KDH3000-CM Security Policy Document Introduction The “Cryptographic Module” for the Kanguru Defender HDD 3000 is the KDH3000- CM, herein after referred to as “cryptographic module” or “module”, (HW Version: 1.0; FW Version: V01.04.0000.0000). It is a FIPS 140-2 Level 2 multi-chip embedded module with an on-chip RISC processor and an integrated hardware cipher engine which supports real time, on the fly AES encryption/decryption of data to secure data at rest. The module is a ruggedized, opaque, tamper-resistant USB disk encryption/file encryption device that connects to an external general purpose computer (GPC) outside of its cryptographic boundary to serve as a secure peripheral storage drive for the GPC. The device connects to the GPC via a Micro USB 3.0/2.0 interface and to the HDD or SSD from a SATA interface. The module is a self-contained device that automatically encrypts and decrypts data copied to and from the drive from the externally connected GPC. All files distributed with the module that are loaded into the GPC (client application and PC configuration data) are excluded from the validation. The Kanguru KDH3000-CM has been specifically designed to address sensitive data concerns of Government and security conscious customers in a variety of markets. Cryptographic Boundary The physically contiguous cryptographic boundary is defined by the outer perimeter of the epoxy covered PCBA of the device. The cryptographic module does not contain any removable covers, doors or openings. The cryptographic module is available in only one approved configuration: Table 1 - Kanguru KDH3000-CM Part  Number   HW  Version   FW  Version   KDH3000 ­CM   1.0   V01.04.0000.0000   The cryptographic module can be connected to various capacities of HDD and SSD. Page 3 of 15 Kanguru Solutions™ KDH3000-CM Security Policy Document The following photographs (Figures 1 – 6) demonstrate the various views of the module. The cryptographic boundary of the module is defined by the area that the epoxy potting covers, which can be seen in Figure 1 – 3 below. Figure 1 – KDH3000-CM – Top side view. The cryptographic boundary is defined by the area that the epoxy potting covers, which is highlighted in red. Page 4 of 15 Kanguru Solutions™ KDH3000-CM Security Policy Document Figure 2 – KDH3000-CM – Bottom side view. The cryptographic boundary is defined by the area that the epoxy potting covers, which is outlined in red. Figure 3 – KDH3000-CM –Right side view. The cryptographic boundary is defined by the area that the epoxy potting covers, which is outlined in red. Page 5 of 15 Kanguru Solutions™ KDH3000-CM Security Policy Document Figure 4 – KDH3000-CM – Front side view demonstrating the Micro USB port. Figure 5 – KDH3000-CM – Back side view demonstrating the LEDs. Page 6 of 15 Kanguru Solutions™ KDH3000-CM Security Policy Document Figure 6 – KDH3000-CM – Left side view demonstrating the SATA port. Security Level Specification Security Requirements Area Level Cryptographic Module Specification 3 Cryptographic Module Ports and Interfaces 2 Roles, Services, and Authentication 3 Finite State Model 2 Physical Security 3 Operational Environment N/A Cryptographic Key Management 2 EMI/EMC 3 Self-tests 2 Design Assurance 3 Mitigation of Other Attacks N/A Exhibit 1 – Security Level Table Approved algorithms The cryptographic module supports the following Approved algorithms for secure data storage: • AES with 256-bit key in XTS mode Encrypt/Decrypt (Cert. #1623) • SHA-256 (Cert. #2144) • NIST800-90 DRBG Hash_DRBG mode with SHA256 core (Cert. #376) Users should reference the transition tables that will be available at the CMVP Web site (http://csrc.nist.gov/groups/STM/cmvp/). The data in the tables will inform users of the risks associated with using a particular algorithm and a given key length. This module provides 256 bits of equivalent encryption strength. Non-Approved algorithms Page 7 of 15 Kanguru Solutions™ KDH3000-CM Security Policy Document NDRNG (HWRNG to generate seeds for the DRBG) • Physical Ports and Logical Interfaces A single physical Micro USB3.0/2.0 port is exposed on the top front side of the module (see Figure 4) that supports all logical interfaces (data input, data output, control input, status output, power) from the GPC. A SATA port (see Figure 6) is exposed at the side for data interface with the storage disk. Two light emitting diodes (LEDs) are located at the bottom of epoxied unit for power and status output. The cryptographic module does not contain a maintenance interface. Exhibit 2 summarizes the physical ports and logical interfaces: Physical Port Logical Interface Data Output Data Input Micro USB3.0 / 2.0 Control Input Status Output Power Data Output SATA HDD/SSD Data Input Power LED Status Output Exhibit 2 – Specification of Cryptographic Module Physical Ports and Logical Interfaces Security rules The following specifies security rules under which the cryptographic module shall operate in accordance with FIPS 140-2: The cryptographic module does not support a non-FIPS mode of operation and only • operates in an Approved mode of operation. The module is configured at production time with the approved firmware and approved configuration settings. The cryptographic module provides logical separation between all of the data input, • control input, data output and status output interfaces. The module receives external power inputs through the defined power interface. The cryptographic module supports identity based authentication for all services that • utilize CSPs and Approved security functions. The data output interface is inhibited during self-tests, zeroization, and when error • states exist. When the cryptographic module is in an error state, it ceases to provide cryptographic • services, inhibits all data outputs, and provides status of the error. The cryptographic module does not support multiple concurrent operators. • Page 8 of 15 Kanguru Solutions™ KDH3000-CM Security Policy Document When the cryptographic module is powered off and subsequently powered on, the • results of previous authentications are not retained, and the cryptographic module requires the operator to be re-authenticated using identity based authentication. The cryptographic module protects CSPs from unauthorized disclosure, unauthorized • modification and unauthorized substitution. The cryptographic module protects public keys from unauthorized modification, and • unauthorized substitution. The cryptographic module satisfies the FCC EMI/EMC requirements specified by 47 • Code of Federal Regulations, Part 15, Subpart B, Unintentional Radiators, Digital Devices, Class B (i.e., for home use). The cryptographic module implements the following self-tests: • Power-up self-tests o Firmware integrity test (SHA256 HASH verification) o SHA-256 KAT o AES-256 XTS Encrypt KAT o AES-256 XTS Decrypt KAT o SP800-90 DRBG KAT o Critical functions Test: Continuous test on non-Approved NDRNG (HWRNG) Conditional self-test o Continuous test on SP800-90 DRBG o Continuous test on non-Approved NDRNG (HWRNG) o Critical functions: CSP integrity test (via SHA25 HASH verification) Manual key entry is not supported and the cryptographic module does not implement • manual key entry tests. The cryptographic module does not support bypass capability and does not implement • bypass tests. The module has two LEDs: one LED shows power status, and the other LED • provides status that the module is in the Approved mode of operation or if there is activity. The status indicator output by the module when a power-up self-test or conditional • self-test fails or if the module enters into an error state is flashing on the status output LED in a continuous fashion. All maintenance related services (i.e. maintenance role, physical maintenance • interface, logical maintenance interface) are not applicable. Plaintext CSP output is not supported. • Page 9 of 15 Kanguru Solutions™ KDH3000-CM Security Policy Document The cryptographic module does not contain dedicated physical ports for CSP • input/output. The power interfaces cannot be used to drive power to external targets. • The continuous comparison self-tests related to twin implementations are not • applicable. Upon authenticating into a particular role, it is not possible to switch into another role • without re-authenticating. The cryptographic module does not provide feedback in regards to authentication • data. The finite state model does not support the following states: maintenance, CSP • output. The cryptographic module is not a radio and does not support any wireless interfaces • or OTAR. The requirements of FIPS 140-2 Section 4.11 are not applicable; the cryptographic • module is not designed to mitigate specific attacks beyond the scope of FIPS 140-2. Identification and Authentication Policy Exhibit 3 defines the roles, type of authentication, and associated authenticated data types supported by the cryptographic module: Role Type of Authentication Authentication Data Master/Cryptographic Identity-based Password (8 to 136 bytes) Officer: responsible for initialization, physical security inspection, and administrative functions. User: the end user of the Identity-based Password (8 to 136 bytes) product that utilizes the module under the direction of the Master/Cryptographic Officer. Exhibit 3 - Roles and Required Identification and Authentication (FIPS 140-2 Table C1) In order to properly initialize the module to operate in FIPS Approved mode after receiving the module from the factory, the Master/Cryptographic Officer must: 1) Authenticate using the factory default password. 2) Run the doIdentify command to verify that the drive is unlocked. 3) Change the Master/Cryptographic Officer Password. Page 10 of 15 Kanguru Solutions™ KDH3000-CM Security Policy Document Exhibit 4 defines the strength of the implemented identity-based authentication mechanism (password verification) by discussing the probabilities associated with random attempts, and multiple consecutive attempts towards subverting the implemented authentication mechanisms: Authentication Mechanism Strength of Mechanism: Strength of Mechanism: Random attempted Multiple consecutive breach attempts in a one-minute period Password verification Less than 1/256^8 Less than 25/256^8 The module zeroizes after 25 failed attempts. Exhibit 4 - Strengths of Authentication Mechanisms (FIPS 140-2 Table C2) Access Control Policy The list of roles, services, cryptographic keys & CSPs, and types of access to the cryptographic keys & CSPs that are available to each of the authorized roles via the corresponding services. Role Type(s) of Cryptographic Keys & Master/ Service Access to No Role CSPs Cryptographic User CSPs Officer SelfTests: performs the full suite of N/A N/A X required power-up self-tests. EnumerateDevices: This function polls N/A N/A the computer to find attached devices X and returns device names and mount locations. OpenSession: This function uses the N/A N/A X device mount location to open a session for sending sensitive data to the module CloseSession: This function tells the N/A N/A X controller to close the session doIdentify: This function gets status N/A N/A X X X information from module (Show Status) doAuthInit: This function generates Master/Cryptographic Enter, keys to restrict access to the encrypted Officer Password Store (private) area of the module. DEK (Data Encryption/ Generate, X Data Decryption Key) Store KEK (Key Encryption/Key Generate, Decryption Key) Store Page 11 of 15 Kanguru Solutions™ KDH3000-CM Security Policy Document NDRNG Seeds Generate DRBG Internal State (C Generate and V) Master/Cryptographic Enter, doAuthAdmin: This function unlocks Officer Password Verify the device using Master/Cryptographic Officer Password, so disk can be DEK (Data Encryption/ Execute mounted X Data Decryption Key) KEK (Key Encryption/Key Execute Decryption Key) User Password Enter, doAuthUser: This function unlocks the Verify device using User Password, so disk can be mounted DEK (Data Encryption/ Execute X Data Decryption Key) KEK (Key Encryption/Key Execute Decryption Key) addUserPassword: This function sets User Password Enter, the User Password to the module to Verify restrict access to the encrypted (private) DEK (Data Encryption/ area of the module. Data Decryption Key) Execute X KEK (Key Encryption/Key Execute Decryption Key) removeUserPassword: This function N/A Enter, X unauthenticates the user password Execute doUnAuth: This function closes N/A N/A (disables access to) the encrypted X X (private) area of module so that this area cannot be accessed. isUnlocked: This function gets the N/A N/A X X status of the encrypted partition changePasswordUser: This function Master/Cryptographic Enter, changes the User Password from old Officer Password Verify, X password to new password. Update changePasswordAdmin: This function User Password Enter, changes the Master/Cryptographic Verify, X Officer Password from old password to Update new password. N/A N/A setReadAddress: This function sets the beginning of the read address for the hidden area. The controller converts the offset to the X memory address and sets a pointer to it. Sequential reads increment the pointer address automatically Page 12 of 15 Kanguru Solutions™ KDH3000-CM Security Policy Document N/A N/A setWriteAddress: This function sets the beginning of the write address for the hidden X area. The controller converts the offset to the memory address and sets a pointer to it. Sequential writes increment the pointer address automatically N/A N/A readChunk: Requests from the controller to X return a 256byte chunk of data from the hidden area. The chunk is read from the address that was set with setReadAddress N/A N/A writeChunk: Tells the controller to write a X 256byte chunk of data to the hidden area. The chunk is written to the address that was set with setWriteAddress. N/A N/A eraseSector: Tells the controller to erase a X 4k sector of the hidden area. Blocks are overwritten with zeroes. N/A N/A writeVcdEnable: This function tells the controller to either allow or disallow writing to the CD-Rom partition. There is a memory X address in SRAM that is configured and checked by the update functions before writing is permitted. The controller changes this bit depending on the parameters of this function. N/A N/A writeVcdBlock: This function sends a block X of 512bytes to the controller for writing to the CD-Rom partition. N/A N/A GetLastSystemError: This function returns X the last error that occurred while running the application. X All CSPs Destroy Zeroize: Actively destroys all CSPs. Exhibit 5 – Services Authorized for Roles, Access Rights within Services (FIPS 140-2 Table C3, Table C4) Physical Security Policy The following physical security mechanisms are implemented by the cryptographic module: • Production grade components • Opaque tamper resistant epoxy without any gaps or openings • Strong adhesive materials that prevent dismantling the module without causing severe damage. • Chips and pin connectors are coated with epoxy. Page 13 of 15 Kanguru Solutions™ KDH3000-CM Security Policy Document NOTICE: The FIPS 140-2 Area 5 physical security testing was performed at ambient temperature; Kanguru Solutions does not claim any FIPS 140-2 Area 5 physical security protection beyond the ambient temperature. Exhibit 6 summarizes the actions required by the Master/Cryptographic Officer Role to ensure that physical security is maintained. Physical Recommended Security Frequency of Inspection/Test Guidance Details Mechanisms Inspection/Test Production grade N/A N/A components Opaque As often as Inspect the entire perimeter for scratches, non-removable feasible scrapes, gouges, cuts and any other signs of potting material tampering. Remove the unit from service when any such markings are found. Exhibit 6 - Inspection/Testing of Physical Security Mechanisms (FIPS 140-2 Table C5) Mitigation of Other Attacks Policy This module is not designed to mitigate against any attacks that are outside the scope of FIPS 140-2. Other Mitigation Specific Attacks Mechanism Limitations N/A N/A N/A Exhibit 7 - Mitigation of Other Attacks (FIPS 140-2 Table C6) Page 14 of 15 Kanguru Solutions™ KDH3000-CM Security Policy Document Acronyms • HDD – Hard Disk Drive • SSD – Solid-State Drive • PCBA – Printed Circuit Board Assembly References • FIPS PUB 140-2 • FIPS PUB 140-2 DTR • FIPS PUB 140-2 Implementation Guidance • FIPS 197 - AES • FIPS 180-4 - SHS • RSA PKCS#1 V2.1 • SP800-90 Page 15 of 15