Cisco Blogs


Cisco Blog > Security

Great Cipher, But Where Did You Get That Key?

Today, there are many strong cryptographic algorithms and protocols, standards for their use at every layer of the network, and interoperable implementations in many products and in open source. When used appropriately, they provide strong safeguards against attacks that target our networks. Unfortunately, none of this good cryptography will protect anybody if it is used with secrets that are guessable.

Humorist Gene Weingarten claims he knows the secrets that protect the U.S. nuclear launch codes: 070494, which happens to be the date of Obama’s daughter’s birthday. No doubt the secrets are actually better chosen than that, but the joke conveys an important truth: you can’t expect everyone to choose passwords well. You should regard passwords that are human-generated or human-memorable as being guessable. A cryptographic system is only as strong as its weakest element. When human-generated keys are used in cryptography, the system should not be expected to resist a knowledgeable attacker.

The most secure key management technology is digital certificates; you should use them when you can. If for some reason you can’t, and you need to use shared secret keys, then you should make sure that those keys are generated by a uniform random process, and not by an administrator in a hurry. I will get to advice on certificates and key generation later, but first, I would like to explain why passwords and cryptography don’t mix well.

Let’s use the Internet Key Exchange (IKE) as an example. IKE establishes the keys that are used to encrypt and authenticate data packets in Internet Protocol Security (IPsec). IKE is a flexible protocol that can provide a great deal of security, which uses the Diffie-Hellman public key protocol to establish shared secrets between two endpoints. It can provide forward secrecy, so that the compromise of a device today will not reveal any of the keys used to encrypt yesterday’s sessions. IKE was designed with an expectation that certificates would be available to authenticate each of the endpoints. However, it can also be used without certificates and instead rely on a Pre-Shared Key (PSK). When a PSK is unpredictable, and only shared between two endpoints, it is every bit as secure as certificates. Many administrators found PSKs easier to use than certificates (who among us would deal with a certification authority if they could avoid it?) and IKE-PSK is now a common practice. But the security ramifications of how PSKs are chosen should be understood.

The IKE standard describes the PSK as “a key derived by some out of band mechanism.” In contrast, some current configuration examples and documentation call it a “group password.” There is a crucial distinction here: a key is generated uniformly at random, while a password is not. This is not just some abstract distinction; it is a difference that is exploitable by an attacker.

IKEv2 became a standard in 2005, but IKEv1 is still widely deployed. IKEv1 can work in either Aggressive Mode or Main Mode, while IKEv2 is simpler and does not have modes. If a poorly chosen PSK is used, then IKEv1 Aggressive Mode is particularly vulnerable. If an endpoint accepts Aggressive Mode exchanges, then an active attacker interacting with that endpoint can get enough data that they can perform an offline dictionary attack against the PSK. In that type of attack, an automated process runs through common passwords and for each candidate password checks to see if that candidate would produce the data that was produced by IKE. Offline dictionary attacks are very powerful; the attacker has many tools at their disposal, including parallel processing and precomputation. An attacker using precomputation can greatly reduce the amount of time needed to find a password; that technique is a time-memory trade-off. An offline dictionary attack is also possible when an attacker on the path of the IKE exchange can passively observe an Aggressive Mode exchange. Additionally, if the attacker is on path and can perform a man-in-the-middle attack and substitute custom messages into the session, then the attacker can gather the information needed to perform an offline dictionary attack against either IKEv1 Main Mode or IKEv2. In this case, the attacker must be the responder; that is, the attacker needs to wait until the intended victim initiates a session. Nonetheless, on-path attacks are easier to perform than you might think, because DNS and ARP cache poisoning can be used during an attack to cause the path of an IKE exchange to go through an attack machine. There are tools to perpetrate dictionary attacks on Aggressive Mode, and a similar tool to attack Main Mode or IKEv2 would not be much harder to construct. In short, offline dictionary attacks on IKE PSKs are a significant threat. These attacks can also be performed against the authentication mechanisms used in OSPF, RIPv2, and TCP-MD5 authentication used to protect BGP sessions. If a pre-shared key is poorly chosen, there is no place for it to hide from a knowledgeable attacker.

If you have to use pre-shared keys, then you should generate them with a tool. The ubiquitous OpenSSL library often comes with a command line tool that can be used to access the library’s functions from a shell. The command ‘openssl rand 16 -base64’ will output 16 bytes of random data. Cisco’s command line interface expects a particular character set: all printable characters except for ‘!’, which indicates the start of a comment. It is not hard to convert a string of random characters into a random string of ‘base 94’ characters, suitable for use as a PSK in Cisco’s CLI. The following short shell script does this by using the POSIX ‘tr’ utility to implement the rejection method. It generates twenty base 94 characters to provide a strength equivalent to a 128-bit key (since 94^20 is slightly greater than 2 to the power 128). The keys produced by this script can be used in OSPF, RIPv2, and TCP-MD5, as well as IKE. This script is easily adaptable to other character sets and to other random sources such as /dev/random. Be sure that the OpenSSL version that you are using doesn’t have a vulnerability in its random source; if you have a recent version, that should not be an issue.

#/bin/sh
# pskgen.sh - generates secret keys

# set environment to "C" to avoid i18n processing that confuses trLC_ALL=C; LANG=C
# base94 is all of the printable characters (octal range 040-176),
# including the space character, except for the '!' character
# (octal 041)
base94="4042-\176"

function usage {
  echo "usage: $0 [-128|-192|-256]";
  echo "  generate random key containing printable characters except !"
  echo "  by default, output is 20 characters (128-bit strength)"
  echo "  -128 causes output of 20 characters (128-bit strength)"
  echo "  -192 causes output of 30 characters (192-bit strength)"
  echo "  -256 causes output of 40 characters (256-bit strength)"
  exit 1
}

hash openssl 2>&- || {
    echo >&2 "error: openssl application not found"
    exit 2;
}

if [ "$#" == "1" ]; then
    if [ "$1" == "-256" ]; then
	keylen=40; # a 256-bit key requires 40 base-94 characters
    elif [ "$1" == "-192" ]; then
	keylen=30; # a 192-bit key requires 30 base-94 characters
    elif [ "$1" == "-128" ]; then
	keylen=20; # a 128-bit key requires 20 base-94 characters
    else
	usage
    fi
elif [ "$#" == "0" ]; then
    keylen=20 # generate a 128-bit key by default
else
    usage
fi

let cropnum=keylen+1; let numbytes=keylen*4
numchars=0
while [ $numchars -lt $keylen ]; do
    X=`openssl rand $numbytes | tr -dc $base94 | colrm $cropnum`
    numchars=${#X}
done
echo "$X"

 

There are several proposals for Password Authenticated Key Exchange (PAKE) protocols that are not vulnerable to offline dictionary attacks. The original was Bellovin and Merrit’s clever Encrypted Key Exchange protocol. In recent years, several protocols that achieve the same end but through different means have been proposed to standards. These PAKE protocols are interesting, and they clearly improve on the security of IKE when a password is used as a PSK. However, they are still vulnerable to online dictionary attacks: an attacker willing to interact with a gateway (which is the same as the attack model as for Aggressive Mode IKE) can guess passwords at will. Given the fact that, in any population of typical users, someone is going to choose a guessable password, this is a consequential flaw.

After a PSK has been chosen, it needs to be distributed to both of the endpoints that use it, in some way that keeps it secret. If all of the VPN devices are provisioned in a single location before they are connected to the network, this is easily done. Otherwise, it is necessary to use a secure communication method such as SSH. (Though beware of the man-in-the-middle attacks against SSH that can happen when there is no verification of the public keys.)

A better idea is to use certificates, and avoid the challenges of key generation and key distribution. With certificates, the device generates a public/private keypair and enrolls the public key with a Certificate Authority (CA) to get a certificate that can be used to authenticate it to anyone that trusts the CA. This is the best option with both IKE and TLS/SSL. The IOS Certificate Server is not a full-featured CA, but it has exactly the functionality that is needed to provide certificates for VPN uses. Many third-party certificate authorities can also be used; the Microsoft CA is popular with enterprises. The Secure Device Provisioning feature can be used to introduce a device to the VPN infrastructure by sharing certificates.

Devices can use certificate enrollment protocols to automatically request certificates, but wouldn’t it be better if certificates were already in place when you bought the box? That is the goal of the 802.1AR Secure Device Identity (SDI) standard. Devices that support this standard come from the manufacturer containing a private key and a corresponding public key certificate issued by the vendor. The certificate contains enough information to identify the manufacturer, the serial number, and other information such as device type. You can think of this standard as a secure and enhanced version of the IEEE Organizationally Unique Identifier. An organization deploying devices that contain Secure Device Identity certificates can remotely authenticate those devices, and establish secure connections with them, based on knowledge of device types and serial numbers. This capability brings a significant change in the scalability of setting up a secure network. Ideally, the organization will issue their own locally significant certificates to the devices, using the SDI certificates to authenticate the certificate enrollment. When these technologies are fully developed, it may be that they make certificates easy enough to use that they gain the prevalence that they deserve. Until then, don’t forget to choose your keys well.

Tags: , , ,

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.

3 Comments.


  1. printf “usage: $0 [-128|-192|-256\n
    generate random key containing printable characters except !\n
    by default, output is 20 characters (128-bit strength)\n
    -128 causes output of 20 characters (128-bit strength)\n
    -192 causes output of 30 characters (192-bit strength)\n
    -256 causes output of 40 characters (256-bit strength)\n” && return 1;

    . . .

    ++ dd if=/dev/ && uuencode

    or, if you insist on using openssl’s mechanism (“`” doesn’t nest well:

    X=$(openssl rand $numbytes | tr -dc $base94 | colrm $cropnum)

    And I disagree. I think that composite mechanisms are better.

       0 likes

  2. Hmm.

    Line 1: “#/bin/sh”

    Ok.

    Line 11: “function usage {”

    What? “function”? Not ok.

    rm -rf pskgen.sh

       0 likes

  3. Hi David

    Excellent post. Here’s a command that will mitigate an IOS device from replying to ikasmp aggressive mode requests.

    crypto isakmp aggressive-mode disable

    http://www.cisco.com/en/US/docs/ios/security/command/reference/sec_c4.html#wp1045707

    When’s the next post please?? :-)

       0 likes