Photo by Cytonn Photography on Unsplash

Say Hello To The EdDSA Standard and FIPS 186–5 (And A Long Goodbye to DSA)

In you are into cybersecurity, what standards should you be audited to? Well, the US government defines a number of standards that many companies comply with, and one of the strongest is FIPS (Federal Information Processing Standard) 140. This standard defines a number of levels that define the security level of a product/system and includes modules tested within the Cryptography Module Validation Program (CMVP).

One of the latests to be defined is FIPS 186–5 on digital signatures, and which adds EdDSA to RSA and ECDSA, but keeps the DSA method only for existing implementations. The original draft for Verison 5 of FIPS 186 was published in 2019, but now the related comments on the draft have been published [here]:

EdDSA uses Curve 25519 with a curve of y²=x³+486662x²+x [plot], and which is a Montgomery curve. The prime number used is 2²⁵⁵−19. EdDSA (Edwards-curve Digital Signature Algorithm) is a fast and efficient digital signature method, and is based on the Schnorr signature scheme. EdDSA has been standardized in [RFC 8032]. With EdDSA, Alice generates a private key of sk and a public key of P=sk.G and where G is the base point of the curve. EdDSA allows for an aggregation of private keys for a signature for a range of parties.

Here are more details on EdDSA:

https://asecuritysite.com/eddsa/

The Beginnings of FIPS 186: DSA

DSA was first outlined by NIST in 1991, within the Digital Signature Standard (DSS). This was then standardized within FIPS (Federal Information Processing Standard) 186 in 1994, and by FIPS 186–4 in 2013. Within FIPS 186–5, though, it is defined that DSA should not be used for the generation of signatures but can be used for signature verification. Most methods now use either RSA or ECDSA signing.

The ECDSA method is basically an extension of DSA, but implemented with elliptic curve (EC) methods. Overall, ECSDA is much more efficient in its computation and in its key sizes.

As with most public key signing methods, in DSA, we take a hash of a message — H(M) — and then apply a private key to create a signature (r,s). This is done by creating a random value (k) to produce the signature. The signature is then verified using the associated public key. This then verifies the creator of the signature and that the message has not been changed.

Initially, Bob creates two prime numbers (p and q) and generates a generator value of g. Next, he generates his secret key (x) and then computes his public key:

To create a signature for a message (M), he creates a random value (k) and then computes two values for the signature:

When Alice receives this signature, she takes Bob’s public key (p,q,g,Y) and the message and computes:

She then checks that v is equal to r . If so, the signature checks out. This works because:

The DSA has left a legacy, though, and the approach has been integrated into the elliptic curve signature method of ECDSA.

FIPS 140 levels

In 2019, FIPS 140–3 replaced FIPS 140–2. It defines 11 areas of design involved in designing and implementing modules [here][docs]. This includes four security levels for the cryptographic module specification; cryptographic module interfaces; roles, services, and authentication; software/firmware security; operating environment; physical security; non-invasive security; sensitive security parameter management; self-tests; life-cycle assurance; and mitigation of other attacks. Each layer builds on the previous level, and where Level 1 is the lowest level, and Level 4 provides the highest level. For those working in finance and in high-risk areas, Level 3 is often the benchmark, while in defence-related areas, Level 4 would often be applied. Table 1 outlines the differences between the levels.

Table 1: FIPS 140–3 overview

Physical security

For physical security, the tamper-proof nature of the target system is key, and where tamper detection becomes important at the higher levels of security.

Security levels

As Figure 1 illustrates, Level 1 provides a minimum security level, while Level 2 implements methods around role-based authentication, and also integrate physical tamper-evidence. As we move up to Level 3, we integrate identity-based authentication and also has an isolation barrier between the identity system and the place that the keys are stored. This would integrate a secure enclave (such as with the Apple T2 chip), or a hardware security module (HSM).

For Level 4, we see formal models, detailed explanations, and pre/post conditions. It also contains a great integration of tamper detection, with EFP (Environmental Failure Protection) and EFT (Environmental Failure Testing). This would involve testing where other components around the target system were to fail, and for the target to not be compromised. A typical focus is around side channels, such as for radio frequency (RF) or electromagnetic (EM) radiation from devices.

Figure 1: FIP 140 levels

Isolation

For isolation, a method often used is key wrapping, and where a key is protected outside a trusted environment. Within the Cloud, AWS CloudHSM (hardware security module) supports AES key wrapping with the default initialization vector — 0xA6A6A6A6A6A6A6A6- or a user-defined value. This provides a FIPS 140–2 Level 3 environment and where the keys in their raw form are only handled within a trusted cloud instance. The wrapped keys can then exist outside this but only converted into their actual form within the CloudHSM. A key generated within the CloudHSM can then be wrapped for export from the environment, or imported from an external wrapped key. The AWS CLI is on the form which defines a key handle (with -k) and the wrapping key handle (with -w):

> wrapKey -k 7 -w 14 -out mykey.key -m 5Key Wrapped.
Wrapped Key written to file "mykey.key: length 612
Cfm2WrapKey returned: 0x00 : HSM Return: SUCCESS

Approved cryptography

Within FIP140–3, the approved methods are:

• Symmetric key: AES-128, AES-192 and AES-256. Acceptable modes are ECB, CBC, CBC with ciphertext stealing, OFB, CTR, CCM, GCM, XTS, and AES Keywrap. AES is the only approved method, but Triple DES can be used in existing applications (but requires a key length of at least 192 bits).
• Digital Signatures: This requires a security level of 112 bits or more. For RSA signatures, we require the keys to be 2,048 bits or more. For DSA: (2048-bit keys, 224-bit hash); (2048-bit keys, 256-bit hash) and (3072-bit keys, 256-bit hash). For ECDSA and EdDSA we require a key size of 224 bits or more, such as the NIST P-256 curve. Approved curves include NIST P-224, P-256, P-384 and P-521 curves.
• Hashing: For hashing, the SHA-1 is not recommended, as it has been broken. The approved ones are SHA-2 (SHA-224, SHA-256, SHA-384, SHA-512, SHA512/224, and SHA-512/256), and SHA-3 (SHA3–224, SHA3–256, SHA3–384, SHA3–512, SHAKE128, and SHAKE256).
• MAC (Message Authentication Code): HMAC methods must have 112 bits or more, and for the approved AES and hashing ciphers.
• Key exchange. For Diffie-Hellman (DH) we require at least a 2,048-bit prime number, and some of the acceptable methods are MODP-2048, MODP-3072, MODP-4096, MODP-6144, and MODP-8192.

To be FIPS140–2 compliant, a Web server setup can be set up with a mixture of these:

Conclusions

If your company is serious about security, it should be looking to move up the FIPS 140 security levels. In the cloud, the AWS KMS (Key Management System) cryptographic module is matched to FIPS 140–2 Level 2, and with some elements matching to Level 3 — including aspects of physical security:

Questions About Encryption Keys and the Cloud

With FIPS 186–5, we now see the additional of the EdDSA, and which is a more scaleable signature method.