TUCoPS :: Cisco :: cisco07.htm

Cisco PIX Private Link Key Length Issue
Vulnerability

    PIX Private Link key length issue

Affected

    Cisco with all PIX Private Link software through version 4.1.6.

Description

    PIX Private Link is an  optional feature that can be  installed in
    Cisco PIX firewalls.  PIX Private Link creates IP virtual  private
    networks  over  untrusted  networks,  such  as the Internet, using
    tunnels  encrypted  with  Data  Encryption  Standard  (DES) in ECB
    ("electronic   codebook")   mode.    An   error   in   parsing  of
    configuration file commands reduces  the effective key length  for
    the PIX Private Link DES encryption to 48 bits from the nominal 56
    bits.

    If attackers know the details of the key-parsing error in the  PIX
    Private Link software, they will know  8 bits of the key ahead  of
    time.  This reduces the  effective key length from the  attacker's
    point of view from 56 to 48 bits.  This reduction of the effective
    key length reduces  the work involved  in a brute-force  attack on
    the  encryption  by  a  factor  of  256.  That  is,  knowledgeable
    attackers  can,  on  the  average,  find  the  right key 256 times
    faster than they would be able to find it with a true 56-bit key.

    CISCO PIX Private Link feature uses  DES key that is only 48  bits
    in  length.   It  is  not  obvious  straight  away  since  key  is
    internally expanded from 7-bytes  (as entered in command  line) to
    8-bytes  that  is  used  by  DES.  If  you dig into that expansion
    algorithm you'll find that third byte, counting from the right, is
    not used at all. This is how key is expanded:

        #!/usr/local/bin/perl
        # Key used by DES
        @key_data=( 0, 0, 0, 0, 0, 0, 0, 0 );
        # Key entered in LINK statement
        @key_in = ( 0x00, 0x00, 0x00, 0x00, 0x00, 0xda, 0xaa );

        # Key expansion algorithm
        $byte = ($key_in[6] & 0x3F) << 2;
        $key_data[6] |= $byte;
        $byte = ($key_in[6] & 0xC0) >> 5;
        $key_data[5] |= $byte;

        $byte = ($key_in[5] & 0x7F) << 1;
        $key_data[7] = $byte;
        $byte = ($key_in[5] & 0x80) >> 6;
        $key_data[6] |= $byte;
        #
        # Byte 4 (from left) seems to be ignored
        #
        $byte = ($key_in[3] & 0x01) << 7;
        $key_data[1] |= $byte;
        $key_data[0] = ($key_in[3] & 0xFE );

        $byte = $key_in[2] & 0x03;
        $key_data[2] |= ($byte << 6);
        $byte = ($key_in[2] & 0xFC) >> 1;
        $key_data[1] |= $byte;

        $byte = $key_in[1] & 0x07;
        $key_data[3] |= ($byte << 5 );
        $byte = $key_in[1] & 0xF8;
        $key_data[2] |= ($byte >> 2);

        $byte = $key_in[0] & 0x0F;
        $key_data[4] |= ($byte << 4);
        $byte = $key_in[0] & 0xF0;
        $key_data[3] |= ($byte >> 3);
        #
        # Now you can use key in @key_data for encryption

    Although the use of ECB mode is intentional, ECB is not  generally
    considered to be the best mode in which to employ DES, because  it
    tends to simplify  certain forms of  cryptanalysis and may  permit
    certain replay attacks.  Technical details of the relative  merits
    of various encryption modes are beyond the scope of this document.

    What's  worse  is  that  this  has  a  nasty  interaction with the
    weakening of the key down to 48 bits.  In export-weakened SSL, one
    adds  some  public  salt  to  the  40-bit  secret  key,  to   stop
    precomputation attacks;  but note  that CISCO's  algorithm adds no
    salt, so there are  all sorts of precomputation  attacks possible.
    The simplest attack  (``the Exabyte attack'')  is to encrypt  some
    common plaintext block (e.g. "\nlogin: ") under all 2^48  possible
    keys, and store the 2^48 ciphertext results on a big Exabyte tape;
    then each subsequent link-encryption  key can be broken  with O(1)
    effort.   Thanks to  the ECB  mode, such  a common plaintext block
    should be easy to find.  (With a real chaining mode, these attacks
    are not possible under  a ciphertext-only assumption, because  the
    chaining vector serves as a kind of salt.)  A much more  practical
    approach would  use Hellman's  time-space tradeoff.   There, you'd
    need only about 2^32  space (e.g. $100 at  Fry's for a cheap  hard
    disk), plus  you'd need  to do  a 2^48  precomputation.  After the
    precomputation, each subsequent link-encryption key can be  broken
    with about 2^32 trial encryptions.

    The really nasty problem with ECB mode is that the data stream  is
    vulnerable  to  trivial  substitution  attacks.   If the encrypted
    traffic consists of administrative commands, it won't be that hard
    to   collect   a    modest   but    interesting   dictionary    of
    plaintext/ciphertext pairs.  Then  the attacker can forge  command
    strings without ever having to brute force the key itself.

Solution

    There is no configuration  workaround.  The first  regular release
    containing a fix for this problem will be version 4.2.1, which  is
    tentatively scheduled for release in late June 1998. This schedule
    is subject to change. Fixes for the 4.1 software release have  not
    yet been scheduled.  This fix extends the effective DES key length
    to a full 56 bits; ECB mode is still used.

TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH