IPSec is used to transfer data between sites in an encrypted
manner. There are two basic techniques for encrypting information: symmetric
encryption and asymmetric encryption.
With Symmetric encryption both parties share the same key. This
allows the sender to encrypt the information using the shared key and the
receiver to decrypt this using the same key. The main problem then becomes how the
two parties negotiate the same key.
With Asymmetric encryption both parties have their own keys.
The sender encrypts the information using one key and the receiver decrypts the
information using another key.
IPsec uses symmetric encryption and uses Diffie–Hellman
key exchange (DH) to generate the same key at each site. DH works like
this:
- Alice
and Bob agree to use a prime number p
= 23 and base g
= 5.
- Alice
chooses a secret integer a = 6, then sends Bob A
= ga
mod p
- A = 56 mod 23
= 8
- Bob
chooses a secret integer b = 15, then sends Alice B = gb mod p
- B = 515 mod 23
= 19
- Alice
computes s = Ba
mod p
- s = 196 mod 23
= 2
- Bob
computes s = Ab
mod p
- s = 815 mod 23
= 2
- Alice
and Bob now share a secret (the number 2).
If the prime numbers are large enough then the shared secret
is considered to be secure as it would take a long time for a computer to test
all the options.
However the critical problem with DH is that it’s vulnerable
to a man-in-the-middle attack. This basically means that Eve could sit in the
middle and negotiate a secret with Alice and different secret with Bob. Eve
could then listen to all the traffic between Alice and Bob.
IPSec solves this problem by authenticating Alice and Bob
using pre-shared-keys (PSK), Certificates or RSA keys.
This problem of authentication and DH is wrapped up into Internet
Key Exchange (IKE) protocol which IPSec uses to ensure secrecy between the
parties. IKE has two phases, Phase one negotiates the following:
s a) Which prime numbers & base to use
b) Which encryption to use in Phase two
c) Generation of the DH shared secret
d) Authentication of the endpoints using PSK or Certs / RSA
b) Which encryption to use in Phase two
c) Generation of the DH shared secret
d) Authentication of the endpoints using PSK or Certs / RSA
Phase 2 uses the encryption algorithm decided in phase one
to encrypt its packets and within this encryption it negotiates the following
a) The encryption method to use for encrypting the
data packets between the end points (IPsec
b)
The shared secret for this encryption
This potentially means that you could have the different
encryption methods for Phase 2 and IPsec. It would be wise to set these
differently as it increases the overall security of the communications. I would suggest that you use AES256 for Phase 2 and AES 128 for IPsec.
Now consider step 1 of the DH negotiation: “Alice and Bob
agree to use a known prime number p and base g”. The values of p and g are
selected from a pool of well known numbers which we refer to as Diffie-Hellman
Groups. IANA has defined these groups here:
For example Group 2 uses the
following well known numbers:
The prime
is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
Its
hexadecimal value is
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
FFFFFFFF FFFFFFFF
The
generator is 2 (decimal)
Current
best practices say to avoid IKE Groups 1, 2, and 5 and use IKE Group 14 or
24, both of which employ 2048-bit DH.
Encryption comes in two flavours DES or AES. The only other
option is then the key length used for the encryption.
Protocol
|
Key Length
|
Block Size
|
CAST
|
40
|
|
DES
|
56
|
64 Bit
|
3DES (DES applied three times)
|
56*3=168 but really ~112 as its not perfect
|
64 Bit
|
AES-128
|
128
|
128 Bit
|
AES-196
|
196
|
128 Bit
|
AES-256
|
256
|
128 Bit
|
However, you may encounter some security issues depending on
the block size and how much data has to be encrypted. 3DES uses 64-bit blocks,
which can lead to trouble after processing 2^(64/2) blocks, i.e. 32 gigabytes; AES
uses 128-bit blocks, for a limit of 2^(128/2) blocks, i.e. 2^68 bytes, also
known as "quite a lot of data". 2^68 bytes
of data is approximately 20 times the information content of "all human
knowledge."
What this really means is if you choose 3DES for your
encryption and happen to transmit >32 gigabits of data then your DH key
could be extracted. If the keys are never changed, an eavesdropper is listening
in on an IPsec session could be easily compromised.
By setting up a lifetime (of time for IKE phase 1, and Time
and/or Data for IKE phase 2) we cause the tunnels to be torn down and recreated
periodically which reduces the amount of time the attacker would have to decode
and take advantage of our tunnels.
IKE phase 2 doesn't run DH again (since it was run during
IKE phase 1 to generate shared secret keys for both peers). So if the Phase 1 key
is compromised then the Phase 2 negotiation can viewed. However, if IKE phase 2
doesn't want to use the keys created in IKE phase 1 there is an option to run
DH again in IKE phase 2. This 2nd DH is
called PFS (Perfect Forward Secrecy) and if desired the configuration could add
the set pfs xxxx command in the crypto map to implement the PFS.
While this is slower, it makes sure that no keys are
dependent on any other previously used keys; no keys are extracted from the
same initial keying material. This is to make sure that, in the unlikely event
that some key was compromised, no subsequent keys can be derived.
Once the phase-2 negotiation is finished, the VPN connection
is established and ready for use.
No comments:
Post a Comment