TLS Ciphers Recommended

Use: TLS v1.1 and 1.2

Avoid: TLSv1.0 or lower or SSLv3 or lower

TLS Recommended Ciphers:
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

Avoid the following ciphers:
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256

Note: The above DHE ciphers are safe to use only if dh group 14 (2048 bit) key sizes are being used for key exchange.  If a lower dh group size is used with DHE ciphers then your server will be susceptible to the logjam attack.  This setting may have to be set in the openssl code.  There is not a configurable option external to the openssl module.  Apache allows for configuring the dh parameters via their management interface.

The following ciphers use RSA for both authentication and key exchange do not provide perfect forward secrecy :

TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_ SHA256

The problem with this is that using RSA for key exchange does not provide perfect forward secrecy since you are not using ephimeral “one-time use” keys.

* Setup DH parameters to enable ephemeral DH 2048 cipher suites

  • Use X.509v3 certificates for mutual authentication for server to server authentication.
  • Use: secp256r1, secp384r1, secp521r1
  • Server and Client must reject any connections offering SSL 1.0, SSL 2.0, SSL 3.0, TLS 1.0
  • For most websites, using RSA keys stronger than 2048 bits and ECDSA keys stronger than 256 bits is a waste of CPU resources and might impair user experience. Similarly, increasing the strength of the ephemeral key exchange beyond 256 bits for ECDHE has little benefit.
  • Avoid: OpenSSL v1.0.0 and below EOL, v1.0.1 EOL 12/31/16  https://www.openssl.org/policies/releasestrat.html

More info on why not to use ECDH cruves:

The ecdh curves should not be used because they do not provide perfect forward secrecy. The reason is that only Diffie Hellman in ephemeral mode uses “one time use” private keys.  DH and ECDH use values based on the stored certificates.  Chris McNab’s Network Security Assessment book warns “When using DH in a static mode, dh_g, dh_p, dh_Ys, and rand_s are fixed and do not provide forward secrecy.”  Here is another good write-up: http://crypto.stackexchange.com/questions/15329/tls-ssls-usage-of-non-ephemeral-dh-vs-dhe.

 

References:

https://weakdh.org/sysadmin.html

https://www.openssl.org/docs/manmaster/apps/dhparam.html

https://www.commoncriteriaportal.org/files/ppfiles/CPP_ND_V1.0.pdf

https://www.feistyduck.com/books/bulletproof-ssl-and-tls/

https://testssl.sh/openssl-rfc.mappping.html

ISO 27001 and Common Criteria

How does Common Criteria relate to ISO 27001?  ISO 27001:2013 is a standard that covers a company’s Information Security Management System (ISMS).  The big change between the 2005 version and the 2013 version of the ISO 27001 is that all risk is now described in terms of protecting information.

  • Where is the company’s information stored?
  • How is the company’s information secured while in transit?
  • Who has access to the company’s information?

It is no longer asset based, but is information based.  The Risk Assessment starts from Information and not IT products.  In previous releases of the ISO 27001 standard all controls had to come out of Appendix A and that is no longer the case.  A rationale can be given of other controls that are in use.  For example NIST 800-53 controls can be described.  A majority of the standard is about planning.  Controls are not specifically described within the standard.  The controls are detailed in Annex A.

Identification of risks and the controls that will be implemented to mitigate these risks. For example, company A has customer data secured in a database.  Instead of focusing on the database that stores the information, now the standard focuses on the customer data and how to protect it.  The controls in Annex A must be reviewed and an explanation of what controls will be used to secure the data.  Controls outside of Annex A can also be described.  For example, all sessions to the database will be encrypted using SSHv2 or TLS1.1/1.2 according to NIST 800-53.  Privilege roles will be configured on the database so that administrators have varied access based on their specific role.

Clause 7 requires that the ISMS be established, maintained, and improved.

Documented records are required to show that the ISMS is in use and maintained.

Organizations must have a policy for external and internal auditing.

Clause 8 requires that a change control process must be in place.  This can be for any IT related changes to in production assets (ex. routers, databases, web servers, etc.)  This has to be documented.

The focus of the ISO27001:2013 is on information security and integrating the plans, processes, and controls into the company’s processes, policies, and procedures.  It is focused on Information security not IT security.  Although IT security may be implemented to secure the information.

Common Criteria relates to this in that products that have been Common Criteria certified will meet the NIST 800-53 controls and map to the ISO 27001 Annex A controls.  A direct mapping of Common Criteria requirements to NIST 800-53 is provided on the NIAP web site posted with each Protection Profile and Controls.  A link to the NDcPP Requirements document is provided below.

References

NDcPP mapping to NIST 800-53

ISO 27001 (Annex A) mapped to NIST 800-53

SSH Algorithms

For SSHv2 key exchange:

Recommended: diffie-hellmann-group14-sha1 (2048 bit) for SSH key exchange

Allowed:  ecdh-sha2-nistp256, ecdh-sha2-nistp384, and ecdh-sha2-nistp521

Avoid: diffie-hellman-group1-sha1 (768 bit),diffie-hellman-group2-sha1 (1024 bit)

dh group 1 should not be used based on this research paper “Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice.”  In addition, dh group 2 and below are susceptible to the logjam attack.

Using the nistp elliptic curves may be unsafe per SafeCurves web site: http://safecurves.cr.yp.to – Lange and Bernstein.  The nistp curves are still considered to be computationally safe, but can be difficult to implement the NIST ECC correctly per Bernstein and Lange.

All sessions must be rejected if remote client or server is only advertising non Common Criteria compliant algorithms and key sizes in the hello.  Disable export algorithms.

SSH authentication public key algorithms:

Use: ssh-rsa, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-sha2-nistp521, x509v3-ecdsa-sha2-nistp256, x509v3-ecdsa-sha2-nistp384, x509v3-ecdsa-sha2-nistp521

Avoid: ssh-dsa

DSA can be broken when one nonce is known.  See https://projectbullrun.org/dual-ec/documents/dual-ec-20150731.pdf (p. 18)

“If a signature scheme based on the digital signature algorithm (DSA, designed
by NSA) is used for server authentication, the knowledge of just one signature
nonce enables the attacker to compute the server’s secret identity key and thus
to impersonate the server.”

SSH transport data integrity:

Use: hmac-sha1, hmac-sha1-96, hmac-sha2-256, hmac-sha2-512, AEAD_AES_128_GCM, AEAD_AES_256_GCM

Avoid: hmac-md5

SSH transport data encryption:

Use: aes123-ctr, aes256-ctr, AEAD_AES_128_GCM, AEAD_AES_256_GCM

Avoid: aes123-cbc, aes256-cbc

OpenSSH incorrectly implemented AES in cbc mode.  As a result, AES-CBC mode in OpenSSH has exploited by the University of London.  This is a nation state level attack, and is not considered to be an easy attack to implement.

OpenSSH has disabled AES in cbc mode in versions 7.x, 6.9, and 6.7.  See the OpenSSH release notes for more information: https://www.openssh.com/releasenotes.html.  CVE info: http://www.kb.cert.org/vuls/id/958563

Additional Notes:

An interesting distinction between SSH and TLS is that when SSH uses ecdh for key exchange, it is automatically using ephimeral keys.  The “E” in ECDHE is unnecessary because ECDH without ephimeral keys is not supported in SSHv2.

From RFC 5656, section 3.1.2:

 The Elliptic Curve Diffie-Hellman (ECDH) key exchange method
   generates a shared secret from an ephemeral local elliptic curve
   private key and ephemeral remote elliptic curve public key.  This key
   exchange method provides explicit server authentication as defined in
   [RFC4253] using a signature on the exchange hash.

NIST New Password Controls

NIST is currently reinventing its recommended password quality parameters.  In light of the many recent hacks that have been attributed to password breaches due to the use of poorly chosen easy-to-guess passwords.  In NIST 800-63-3, NIST is attempting to make the password policies more user friendly by shifting the burden on the verifier.

No matter how strong your password hashes/cryptography is, if the chosen password is inherently weak, then literally no controls can protect them from disclosure attacks.  Previously NIST’s approach has been to shift the risk more onto the consumer.  The new approach is to shift the burden on to the provider.  To that end, one of the key highlights of the new standard is blacklist validation against a list of “known-bad” passwords.  These are some of the highlights of the new standard:

DO’S :

  • Minimum password length should be 8 characters, with a maximum of no less than 64 characters.
  • Recommended to have a minimum of 12 character password for sensitive sites.
  • All ASCII and UNICODE characters should be allowed even emojis.
  • Blacklist validation against a list of “known-bad” passwords.
  • Allow for an option to read the password during input.

DON’TS:

  • No password composition/complexity rules (Ex: Your password must contain one lowercase letter, one uppercase letter, one number, etc..)
  • No password hints.
  • No Knowledge-based authentication (Ex: Where did you attend high school? What’s your favorite pet?).
  • require passwords to expire unless a breach occurs.

SECURE PASSWORD STORAGE:

Keyed HMAC hash(HMAC-SHA1 or HMAC-SHA2 or HMAC-SHA3 as specified in NIST SP 800-131A rev1, Sec 9.) with 32-bit random salt AND stretched using NIST approved key derivation function (PBKDF2 as specified in NIST SP 800-132) with a minimum of 10,000 iterations.

Out of Band Authenticator

  • Don’t Use SMS
  • Respnse (only) may be over a protected channel
  • OOB device authenticates to verifier using approved crypto

 

  • Thanks to Ram  C. for providing this great information.

References:

https://www.ftc.gov/news-events/blogs/techftc/2016/03/time-rethink-mandatory-password-changes

http://cups.cs.cmu.edu/passwords.html

https://passwordscon.org/archives/vegas-16/

 

 

 

DRBG and RNG

No matter how good your algorithm and key sizes are, a bad random number generator means your cryptography will fail.  Only a hardware Random Number Generator (RNG) is a true RNG.  Software based “RNGs” are called Deterministic Random Bit Generators (DRBGs) because at some point they will repeat.  If you are designing a product, then you need to include a hardware based RNG such as Cavium, ACT2Lite, or another similar hardware processor that creates entropy.  Basically the entropy is created by the processor, conditioned via a hash function and seeded into the DRBG such as CTR_DRBG (AES), HMAC_DRBG (any), AES Hash_DRBG (any) according to NIST SP800-90A Rev 1 (ISO/IEC 18031:2011).  CTR_DRBG (AES) is recommended.

Avoid: DUAL_EC_DRBG and ANSI X9.31 using AES

Dual_EC_DRBG is the DRBG that NSA paid RSA $10 million to make it the default RNG in the RSA BSAFE toolkit.  ANSI X9.31 doesn’t have a back door, but it does not provide perfect forward secrecy (PFS) or backtracking resistance.  If a product does not do backtracking then an attacker can compute earlier random numbers and decrypt earlier encrypted documents.

If you don’t have a processor that also performs hardware based entropy, then use /dev/urandom with truerand.c pulling random data from the clock variance between the real time clock and CPU clock.  The normal entropy gathered from /dev/urandom on linux gets it from mouse clicks, disk controller, and other movements and sounds that have human interaction.  The problem is human movements are not random, so this form of entropy is low meaning not very random.  Using truerand.c provides a better entropy source that can be conditioned (SHA-1) and seeded into the DRBG.

 

References:

http://opensource.apple.com//source/apache/apache-678/mod_ssl/pkg.contrib/truerand.c

https://projectbullrun.org/dual-ec/

 

 

IPsec Algorithms

Use: AES-CTR-128, AES-CTR-256, AES-GCM-128, AES-GCM-256

Avoid: AES-CBC-128, AES-CBC-256

IKEv1 Phase 1 exchanges use only main mode

IKEv1 and IKEv2 SA lifetimes are able to be limited to 24 hours for Phase 1 SAs and 8 hours for Phase 2 SAs.

IKEv1 and IKEv2 SA lifetimes are able to be limited to 100 – 200 MB of traffic.

All IKE protocols implement DH Groups 14 (2048-bit MODP) and above.

Peer Authentication can use RSA and ECDSA

Mutual Authentication with X.509v3 certificates are required.

All sessions must be rejected if remote peer is only advertising non compliant algorithms and key sizes different than listed above.