- Cryptographic Standards
- IPv6 Support
- 128/192/256-bit AES in CBC mode (FIPS 197) [NIST AES Certificate #9]
- 192-bit TDES in CBC mode (FIPS 46-3; ANSI X9.52-1998) [NIST TDES Certificate #115]
- DES in CBC mode (FIPS 46-3/81; ANSI X3.106); decrypt-only (for backward compatibility) [NIST DES Certificate #171]
- EES ("Skipjack"; FIPS 185; SDN.701; requires a FORTEZZA card though a software module can be supplied upon demand) [NIST EES Certificate #9]
- AT&T EA2 in CBC mode (for compatibility with older, "exportable" versions of SA5)
- DESX in CBC mode (for automatic encryption only; replaced by 128-bit AES-CBC in release 5.2.8)
- RC4 with 64-2048 bit keys (for self-decrypting archives only)
Key Exchange Mechanisms:
- RSA (generates 1024/2048/4096/8192-bit keys; supports all recipient key sizes from 512 to 16384 bits; ANSI X9.31; IEEE 1363-2000; RFC2313; PKCS#1v1.5)
- Diffie-Hellman (1024/2048/4096-bit keys; ANSI X9.42-1998; IEEE 1363-2000)
- ECDH (supports 163/233/283/409/571-bit NIST curves in char. 2, 192/224/256/384/521-bit NIST curves in char. p; FIPS 186-3; ANSI X9.42-1988; IEEE 1363-2000)
- KEA (SDN.701; requires a FORTEZZA card and special SecretAgent build)
Digital Signature Schemes:
- DSA (1024/2048/4096-bit keys; FIPS 186-3; ANSI X9.30-1997) [NIST DSA Certificate #65]
- RSA (generates 1024/2048/4096/8192-bit keys; supports all key sizes from 512 to 16384 bits; FIPS 186-3; ANSI X9.31-1998; PKCS#1 v.1.5)
- ECDSA (supports 163/233/283/409/571-bit NIST curves in char. 2, 192/224/256/384/521-bit NIST curves in char. p; FIPS 186-3; ANSI X9.62-1988; IEEE 1363-2000)
Message Authentication Codes:
- SHA-1 ("Secure Hash Algorithm"; FIPS 180-2; ANSI X9.30-1997(2)) [NIST SHA-1 Certificate #100] (command line versions also support SHA-256/384/512)
- MD2 and MD5 (RFC1319/RFC1321; used only for certificate validation with legacy PKIs)
Public Key Infrastructure Support:
- X.509 version 3 RSA, DSA, or ECC certificates (from binary or base64-encoded ASN.1 DER files, or PKCS#7 files)
- Generates self-signed X.509 certificates for use without a PKI; supports browser-based enrollment for use with an existing PKI (the command line version can generate PKCS#10 RSA/DSA/ECC certificate requests to support additional enrollment scenarios)
- Optional CRL support (may be made mandatory using PolicyAgent)
- IETF PKIX key usage certificate extensions (encrypt-and-sign, encrypt-only, sign-only)
- LDAP repository access for certificate retrieval/certificate status; optional OCSP support
- Local and network certificate database access
Encoding & Compression Options:
- A Lempel-Ziv variant (LZSS) is provided for the optional compression of plaintext prior to encryption
- A base64 encoding function is provided for the optional encoding of ciphertext
- MSP output (SDN.701; requires a FORTEZZA card and special SecretAgent build)
Secure File/Disk Erasure:
- integrated file erasure and free space wiping utility conforms
to the latest
Department of Defense National Industrial Security Program OManual (NISPOM) January 1995 (DoD 5220.22-M, Section 8-306, Clearing and Sanitization Matrix method d: "Overwrite all addressable locations with a character, its complement, then a random character and verify.")
PKIX Compliance and DoD PKI Interoperability Testing
SecretAgent uses standard X.509 version 3 certificates with optional
chain validation and CRL checking in compliance with RFC3280. On
most platforms, SecretAgent 5.x can generate standard PKCS#10 certificate
requests (for use with an existing CA) or X.509 version 3 self-signed
certificates (for operation without a formal PKI). We have performed
interoperability testing with all major Certificate Authorities
and PKI vendors (e.g., Entrust, RSA, Verisign, XCert).
|In October 2002, SecretAgent 5.6 for Windows passed interoperability testing at DISA's JITC PKE Certification Lab at Ft. Huachuca and received formal certification of full compliance with the DoD PKI. (JITC's Interoperability Test Summary.) The JITC test was based on NIST's "Conformance Testing of Relying Party Client Certificate Path Procesing Logic," Version 1.07, Sept. 28, 2001. SecretAgent releases 5.7-5.10 also pass these tests. SecretAgent 6.0.3 was recertified as fully interoperable with the DoD PKI on February 2, 2010. According to the new certification memo, JITC has found SecretAgent to be compliant with "the applicable requirements defined in Department of Defense Class 3 Public Key Infrastructure Public Key-Enabled Application Requirements," 1.0, 13 July 2000.|
SecretAgent 5.8–5.10 and 6.x were designed for full compliance with the recently expanded NIST "Public Key Interoperability Test Suite (PKITS) Certificate Path Validation," Version 1.0, Sept. 2, 2004. The Path Validation Modules (PVMs) in these builds are also "(Federal) Bridge-Enabled," satisfying all requirements in Sections 3 and 4 of NIST Draft Special Publication 800-XXX, NIST Recommendation for X.509 Path Validation, Version 0.5, May 3, 2004.
In addition to the native .sa5 file format supported by SecretAgent on all platforms, Release 6.0 (as well as 5.7 and above for Windows, UNIX, and Mac OS X) support the following:
- S/MIME v3 CMS (RFC3852) — encrypt/decrypt/sign/validate; support for enveloped and detached signatures included
Releases 5.7–5.9 for Windows also supported:
- OpenPGP (RFC2440) — certificate-based encrypt/decrypt only; OpenPGP signatures are not supported
CMS support provides interoperability with several S/MIME v3 clients, such as Microsoft Outlook Express and OpenSSL. OpenPGP support provides interoperability with PGP 6/7/8, Gnu Privacy Guard, and other RFC2440-compliant applications. OpenPGP interoperability matrix.
SecretAgent 5.6 and above fully satisfy NIST FIPS 140-2 as well as DoD/CNSS NSTISSP No. 11 acquisition requirements for COTS security and information assurance products.
For the list of cryptographic schemes employed by SecretAgent 5.x and 6.x, see the next tab.
Addressing a Popular FIPS 140-2 vs. FIPS 140-1 Misconception
Even though 140-2 is the current standard, products validated under 140-1 have not been deprecated. According to NIST, U.S. Government "agencies may continue to purchase, retain and use FIPS 140-1 validated modules after May 25, 2002. Modules validated as conforming to FIPS 140-1 and FIPS 140-2 are accepted by the Federal Agencies of both [the U.S. and Canada] for the protection of sensitive information." Furthermore, "Cryptographic modules that have been approved for classified use may be used in lieu of modules that have been validated against this standard [FIPS 140-2]." (Quoted text taken from NIST website on 3/26/07.)
As of March 30, 2010, NIST's position on this matter is the following:
"After May 25, 2002, all previous validations against FIPS 140-1 WILL STILL BE RECOGNIZED...
Clarification: Agencies may continue to purchase, retain and use FIPS 140-1 validated products
after May 25, 2002."
There is NO reasonable basis for believing that FIPS 140-2 validated products are any more secure than FIPS 140-1 validated products, yet the myth persists. In fact, the principal basis for judging the strength and FIPS compliance of any cryptographic module lies in the NIST algorithm certificates it has been awarded and exactly the same certificates are used for both 140-1 and 140-2 validations. Once issued, an algorithm certificate remains valid as long as the relevant NIST standard remains in effect for that algorithm.
IPv6 Support in SecretAgent
In general, SecretAgent supports IPv6 addressing wherever IPv4 addressing is supported. If IPv6 support is not provided by the underlying operating system (either because the OS does not support IPv6 or because the IPv6 stack for the operating system or network adapter has not been properly configured), SecretAgent will recognize IPv6 addresses, but not use IPv6 transport mechanisms.
SecretAgent running on Windows XP SP3, Windows Vista, Window 7 or Windows 8 does fully support IPv6 in both pure and mixed environments.