Technology

Suite B Cryptography

Special Type 1 encryption products with Suite A cryptographic algorithms are typically used to protect classified or sensitive government data. These devices and algorithms are controlled by the National Security Agency (NSA). These products take years to construct and certify the typically custom hardware and software to a stringent set of requirements.

These products have strict security controls for storage, operation, accounting, and authorizing use to prevent them from falling into the wrong hands. These are part of the device being classified as a Cryptographic Controlled Item (CCI) that must adhere to the COMSEC Material Control System (CMCS). These makes the devices expensive to own, operate and maintain. It also makes it difficult to share these devices with Coalition partners, state and local police, first responders, or use in unattended or uncontrolled environments. It also naturally limits the market to which they may be sold, increasing expense, and reducing technological innovation turn-around time causing the devices to continually be obsolete in comparison to commercial technology that progresses at a faster pace. When combined with the explosive growth in the communications product sector and reduced government budgets, a new approach needed to be taken.

To partly address these issues the NSA defined the Suite B Cryptographic standard that is based on unclassified algorithms such as AES and Elliptic Curve techniques as defined by NIST FIPS-197 and NIST SP800-56A respectively. Suite B is part of the NSA Cryptographic Interoperability Strategy (CIS) that was developed to meet the needs outlined above. Open standards and public algorithms provide interoperability, using large key sizes for these algorithms provides strong security, allowing for the unclassified, non-CCI devices to be used to protect sensitive but unclassified (SBU) as well as some classified information, up to the SECRET level with NSA approval.

The NSA is also developing a new Commercial Solutions Partnership Program (CSPP) that combines COTS information assurance products to form a protection solution up to the SECRET level. The program uses either the NIAP Common Criteria Evaluation and Validation Scheme (CCEVS), or the NIST Cryptographic Module Validation Program (CMVP) which is the process for the FIPS-140 certifications many commercial products have obtained.

To provide the strongest protection for commercial, government, and military use on the latest commercial platforms, the SAIFE cryptographic modules are Suite B compliant and are currently undergoing FIPS validation. The “Cummings Engineering’s Secure Mobility Suite B Crypto Module” is in the “Coordination” phase on the FIPS pre-val list of certifications that are under way. Our solutions are expected to meet, at a minimum, the following recognized security standards, rules, and regulations:

NSA Tactical Secret
NSA Suite B Algorithms
FIPS 140-2 evaluation pending

Additionally, the technology:

Complies with DISA STIG Application Security and Development, MAC II for Classified information.
Designed for Common Criteria EAL4: Methodically Designed, Tested, and Reviewed
Designed for compliance with National Security Agency’s (NSA) Suite-B protection standard and Cryptographic Interoperability Strategy (CIS)

Certifications and Compliance

Algorithms

Name	Validation No	Validation Date	Description
AES	1916	1/26/2012	ECB ( e/d; 128 , 192 , 256 ); CBC ( e/d; 128 , 192 , 256 ); CFB1 ( e/d; 128 , 192 , 256 ); CFB8 ( e/d; 128 , 192 , 256 ); CFB128 ( e/d; 128 , 192 , 256 );OFB ( e/d; 128 , 192 , 256 ); CTR ( ext only; 128 , 192 , 256 ); CCM (KS: 128 , 192 , 256 ); CMAC (Generation/Verification ); GCM (KS: AES_128( e/d ) Tag Length(s): 128 120 112 104 96 64 32 ) (KS: AES_192( e/d ) Tag Length(s): 128 120 112 104 96 64 32 ) (KS: AES_256( e/d ) Tag Length(s): 128 120 112 104 96 64 32 ) IV Generated: ( Internally ); XTS( KS: XTS_128( (f) ) KS: XTS_256( (f) ))
Triple DES	984	1/26/2012
DSA	607	1/26/2012	FIPS186-2: PQG(gen) MOD(1024); PQG(ver) MOD(1024); KEYGEN(Y) MOD(1024); SIG(gen) MOD(1024); SIG(ver) MOD(1024); SHS: Val# 1692 RNG: Val# 1014 DRBG: Val# 168 FIPS186-3: PQG(gen)PARMS TESTED: [ (1024,160) SHA( 1 , 224 , 256 , 384 , 512 ); (2048, 224)SHA( 224 , 256 , 384 , 512 ); (2048,256)SHA( 256 , 384 , 512 ); (3072,256) SHA( 256 , 384 , 512 ) ] PQG(ver)PARMS TESTED: [ (1024,160) SHA( 1 , 224 , 256 , 384 , 512 ); (2048,224) SHA( 224 , 256 , 384 , 512 ); (2048,256) SHA( 256 , 384 , 512 ); (3072,256) SHA( 256 , 384 , 512 ) ] Key Pair: [ (1024,160) ; (2048,224) ; (2048,256) ; (3072,256) ] SIG(gen)PARMS TESTED: [ (1024,160) SHA( 1 , 224 , 256 , 384 , 512 ); (2048,224) SHA( 1 , 224 , 256 , 384 , 512 ); (2048,256) SHA( 1 , 224 , 256 , 384 , 512 ); (3072,256) SHA( 1 , 224 , 256 , 384 , 512 ); ] SIG(ver)PARMS TESTED: [ (1024,160) SHA( 1 , 224 , 256 , 384 , 512 ); (2048,224) SHA( 1 , 224 , 256 , 384 , 512 ); (2048,256) SHA( 1 , 224 , 256 , 384 , 512 ); (3072,256) SHA( 1 , 224 , 256 , 384 , 512 ) ]
RSA	984	1/26/2012	FIPS186-2: ALG[ANSIX9.31]: Key(gen)(MOD: 1024 , 1536 , 2048 , 3072 , 4096 PubKey Values: 3 , 17 , 65537 ALG[ANSIX9.31]: SIG(gen); SIG(ver); 1024 , 1536 , 2048 , 3072 , 4096 , SHS: SHA-1, SHA-256, SHA-384, SHA-512 ALG[RSASSA-PKCS1_V1_5]: SIG(gen), SIG(ver): 1024 , 1536 , 2048 , 3072 , 4096 , SHS: SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 ALG[RSASSA-PSS]: SIG(gen); SIG(ver); 1024 , 1536 , 2048 , 3072 , 4096 , SHS: SHA-1, SHA-224, SHA-256, SHA-384, SHA-512
ECDSA	272	1/26/2012	FIPS186-2: PKG: CURVES( P-192 P-224 P-256 P-384 P-521 K-163 K-233 K-283 K-409 K-571 B-163 B-233 B-283 B-409 B-571 ) PKV: CURVES( P-192 P-224 P-256 P-384 P-521 K-163 K-233 K-283 K-409 K-571 B-163 B-233 B-283 B-409 B-571 ) SIG(gen): CURVES( P-192 P-224 P-256 P-384 P-521 K-163 K-233 K-283 K-409 K-571 B-163 B-233 B-283 B-409 B-571 ) SIG(ver): CURVES( P-192 P-224 P-256 P-384 P-521 K-163 K-233 K-283 K-409 K-571 B-163 B-233 B-283 B-409 B-571 )FIPS186-3: PKG: CURVES( ALL-P ALL-K ALL-B ) PKV: CURVES( ALL-P ALL-K ALL-B ) SigGen: CURVES( P-192: (SHA-1, 224, 256, 384, 512) P-224 (SHA-1, 224, 256, 384, 512) P-256: (SHA-1, 224, 256, 384, 512) P-384: (SHA-1, 224, 256, 384, 512) P-521: (SHA-1, 224, 256, 384, 512) K-163: (SHA-1, 224, 256, 384, 512) K-233: (SHA-1, 224, 256, 384, 512) K-283: (SHA-1, 224, 256, 384, 512) K-409: (SHA-1, 224, 256, 384, 512) K-571: (SHA-1, 224, 256, 384, 512) B-163: (SHA-1, 224, 256, 384, 512) B-233: (SHA-1, 224, 256, 384, 512) B-283: (SHA-1, 224, 256, 384, 512) B-409: (SHA-1, 224, 256, 384, 512) B-571: (SHA-1, 224, 256, 384, 512) ) ) SigVer: CURVES( P-192: (SHA-1, 224, 256, 384, 512) P-224 (SHA-1, 224, 256, 384, 512) P-256: (SHA-1, 224, 256, 384, 512) P-384: (SHA-1, 224, 256, 384, 512) P-521: (SHA-1, 224, 256, 384, 512) K-163: (SHA-1, 224, 256, 384, 512) K-233: (SHA-1, 224, 256, 384, 512) K-283: (SHA-1, 224, 256, 384, 512) K-409: (SHA-1, 224, 256, 384, 512) K-571: (SHA-1, 224, 256, 384, 512 B-163: (SHA-1, 224, 256, 384, 512) B-233: (SHA-1, 224, 256, 384, 512) B-283: (SHA-1, 224, 256, 384, 512) B-409: (SHA-1, 224, 256, 384, 512) B-571: (SHA-1, 224, 256, 384, 512) )
SHS	1681	1/26/2012	SHA-1,SHA-224, SHA-256, SHA-384, SHA-512
RNG	1007	1/26/2012	ANSI X9.31 [ AES-128Key AES-192Key AES-256Key ]
DRBG	161	1/26/2012	Hash_Based DRBG: [ ( SHA-1 , SHA-224 , SHA-256 , SHA-384 , SHA-512 ) ( SHS ) ] HMAC_Based DRBG: [ ( SHA-1 , SHA-224 , SHA-256 , SHA-384 , SHA-512 ) ( HMAC ) ] CTR_DRBG: [ BlockCipher_Use_df: ( AES-128 , AES-192 , AES-256 ) ( AES ) ] BlockCipher_No_df: ( AES-128 , AES-192 , AES-256 ) ( AES ) ] Dual_EC_DRBG:[ ( P-256: SHA-1 , SHA-224 , SHA-256 , SHA-384 , SHA-512 ) ( P-384: SHA-224 , SHA-256 , SHA-384 , SHA-512 ) ( P-521: SHA-256 , SHA-384 , SHA-512 ) ]
HMAC	1151	1/26/2012	HMAC-SHA1 (Key Sizes Ranges Tested: KSBS ) SHS HMAC-SHA224 ( Key Size Ranges Tested: KSBS ) SHS HMAC-SHA256 ( Key Size Ranges Tested: KSBS ) SHS HMAC-SHA384 ( Key Size Ranges Tested: KSBS ) SHS HMAC-SHA512 ( Key Size Ranges Tested: KSBS )
SP800-56A Component	13	1/26/2012	Curves tested: P-192, P-224, P-256, P-384, P-521, K-163, K-233, K-283, K-409, K-571, B-163, B-233, B-283, B-409, B-571

Network Connectivity

There are many types of network access points these days, from WiFi to cellular data, to satellite and more. They exist at every conceivable physical location around the globe. Mobile products can connect to and establish data sessions across any of them. While this presents a wonderful physical mobility for the user, it creates a a device that randomly appears and disappears from the network and at different locations, causing connections to drop, packets to be lost, and security sessions to be torn down as users physically move around and reconnect to networks at different points.

Further, most public network providers have to scale their IP address ranges through the use of Network Address Translator (NAT) routers rather than provide a unique Internet IP address for every device that connects to their network. This NAT-assigned IP address is not visible to other devices connected to the Internet, impeding the ability to connect devices that wish to share data but are connected to different networks. To make it even more complex, most home and public networks have firewalls that block incoming connection requests from outside their network. Even when using a custom network that overcomes these complexities, the nature of IP networks is to route packets based on a geographic location of the device. Once it moves outside a certain geographic area, the network is no longer able to route packets to the device without assigning it a new IP address.

The SAIFE Continuum and SAIFE Black Connection Gateway (BCG) are cloud services architected for high Quality of Service and responsiveness world-wide. Mobile devices are automatically routed to the closest SAIFE service provider for optimal performance. Alternatively, customers can license their own dedicated SAIFE cloud services for use on public or closed networks.

The BCG is used to relay packets for secure sessions between devices and transfer the session as the mobile device crosses network boundaries. When a user initiates a secure session with another device, the device requests access to the nearest BCG service provider and obtains the network information necessary to provide a connection between itself and other devices. When two devices can directly see each other on the network the BCG is not used, or can be selectively used if the mobile user desires the extra mobility or anonymity the BCG provides. When the network topology prevents the two devices from seeing each other directly, perhaps due to a NAT router or Firewall, the BCG becomes a packet relay for the duration of the secure session. The BCG is application independent such that it supports Voice, Text, Video or any other imaginable data stream. The BCG only handles encrypted or non-sensitive information making it a black gateway.

The SAIFE Continuum service accounts for the mobility and discontinuous network availability of a mobile device user, as well as SAIFE-Management. It provides a presence server for initiating secure connections between devices across any network topology; as well as a store-and-forward service in both directions for remote configuration, audit logs, key signing and revocation, software updates, and other management services. All messages between SAIFE-Management and a SAIFE-SDK mobile device are cryptographically signed and encrypted, thus the SAIFE Continuum never stores nor has access to any sensitive information for any device it facilitates.