On CIA Crypto

On Tuesday, Wikileaks released a tranche of alleged Top Secret CIA documents, many involving explanations of their cryptographic requirements.   Reading through the documents turned out to be anticlimactic, the CIA’s cryptographic requirements are pretty boring, and that is how it usually works in cryptography.

Quoting from the document, “These requirements are intended to ensure a satisfactory minimum level [my emphasis] of security for tools used to advance the CIA’s intelligence collection activities”. What CIA means here is not a minimum cryptographic level of security, as opposed to potentially stronger crypto, but instead CIA  means that cryptography is absolutely necessary in order to protect their software from detection, to ensure covert exfiltration of data, and to protect the confidentiality of the data exfiltrated—I’ll refrain from a pun involving confidentiality, integrity, authenticity.

Below I’ll first discuss the five crypto suites specified by CIA, then I’ll highlight some other points from the CIA document.

The crypto suites

Five crypto suites are specified, with the first three for network communications, which are essentially requirements for a TLS 1.2-like protocol:

• The Long-lived Suite, “for use with tools residing on a target or redirector for longer than one working day”, and the strongest of the three suites, prescribes:
  • A key exchange with 2048-bit Diffie-Hellman, 2048-bit RSA, or 256-bit elliptic-curve Diffie-Hellman (but recommends against RSA, to ensure forward secrecy)
  • Digital signature with DSA, RSA, or ECDSA, with the same 2048- or 256-bit parameters size
  • Mutual authentication (thus using a client certificate)
  • Pinning, in the form of a pre-shared certificate
  • Message integrity using HMAC based on SHA-256, SHA-384, or SHA-512
  • Message confidentiality using AES-CBC, -CTR, or -GCM (which is odd, since there’s already HMAC and GCM without tags is essentially CTR).
• The Short-lived Suite,  “for use with tools residing on a target or redirector for less than one working day”, is similar to the Long-lived Suite but accepts HMAC-based “authentication”, as opposed to only public-key signatures. It’s not really clear to me what “authentication” refers to here, since CIA distinguishes HMAC for integrity from HMAC for authentication. I’d be happy to get clarifications from readers or CIA employees here.
• The Weak Suite, apparently to support legacy systems, allows weaker algorithms: HMAC-SHA-1, 1024-bit RSA and DSA, and block ciphers Serpent, Twofish, Blowfish, 3DES, as well as the stream cipher (or “pseudo one-time pad” in CIA parlance) RC4. But RC4 is only accepted if the first 3072 bytes of keystream (what CIA calls “cryptostream”) are discarded, to hide the most obvious biases from RC4’s key schedule.

The long- and short-lived suites impose 256-bit symmetric keys, for HMAC and AES, but inconsistently use 2048-bit RSA/DSA and 256-bit elliptic curves, which get you 128-bit security. The weak suite allows 128-bit symmetric keys, but allows 1024-bit RSA/DSA.

There are two other crypto suites:

• The Collection Encryption Suite, for protecting “collected information” (stolen from infected systems). Files or data blobs should be encrypted with 256-bit key AES, again in CBC, CTR, or GCM mode (but without the authentication features; I assume that CIA mentions GCM and not only CTR in case a library is only available for GCM). Ciphertexts’ digests should then be signed, “using the sender’s preshared asymmetric private key”, 2048-bit RSA/DSA or 256-bit elliptic curves (ECDSA isn’t explicitly cited though).
• The Tool State Encryption Suite,  for protecting tools and their associated files, with the same set of primitives as the Collection Encryption Suite.

So that’s all pretty standard crypto.

The best practices

CIA makes a bunch of recommendations, sometimes familiar, but sometimes ignoring crypto orthodoxy:

Don’t roll your own crypto™:  CIA criticized NSA’s so-called Equation Group for using custom crypto, and recommends that their tools stick to NIST standards, and mandates the use of platform-provided libraries (the document cites Microsoft CryptoAPI-NG, OpenSSL, PolarSSL, GnuTLS, etc.).

Message compression before encryption is made mandatory, and justified as follows: “Compression reduces the amount of information to be encrypted, thereby decreasing the amount of material available for cryptanalysis. Additionally, compression is designed to eliminate redundancies in the message, further complicating cryptanalysis.” I can understand that compression makes for shorter files and therefore simplifies exfiltration of stolen information, but in general you shouldn’t follow CIA’s recommendation. That’s because the size of the compressed message depends on the content of the original message, and therefore leaks information on the message (remember CRIME?).

Rekeying (that is, change of encryption key after a certain amount of data is encrypted) is recommended, for “minimizing key exposure”. CIA hints at weaknesses in certain algorithms, but notes that “[the] exact nature of which algorithms are weak at this stage is highly classified.” I can assume that they refer to AES-GCM’s limitations, as well as to blocks ciphers with 64-bit blocks.

Decryption with proof-of-work is called Random Decryption Algorithm (RDA), described as a “whereby a piece of malware does not possess the decryption key for its own main execution component”. In short, the execution of the malware would start with a brute force step in order to find the correct decryption key necessary to decrypt the malware’s main program. That’s nothing new though, malware authors have been using this simple trick to avoid detection, for example by execution sandboxes.

So there’s nothing really exciting here, CIA is using crypto from the 90’s, but it seems to be enough to fit their needs. For malware crypto is just a tiny piece of the puzzle, where priorities are to avoid detection and to minimize the forensics footprint. It therefore makes sense to stick to standard crypto and reuse platform components rather than bring new sophisticated schemes.