diff options
author | Benoît Ganne <bganne@cisco.com> | 2022-01-18 15:56:41 +0100 |
---|---|---|
committer | Beno�t Ganne <bganne@cisco.com> | 2023-03-23 08:59:31 +0000 |
commit | 5527a78ed96043d2c26e3271066c50b44dd7fc0b (patch) | |
tree | 3e4186cb439e10051d013cc71c1f7d8d81ad9613 /src/vppinfra/tw_timer_16t_2w_512sl.c | |
parent | ad95b06181c354291f4433c5e550cb89c5122252 (diff) |
ipsec: make pre-shared keys harder to misuse
Using pre-shared keys is usually a bad idea, one should use eg. IKEv2
instead, but one does not always have the choice.
For AES-CBC, the IV must be unpredictable (see NIST SP800-38a Appendix
C) whereas for AES-CTR or AES-GCM, the IV should never be reused with
the same key material (see NIST SP800-38a Appendix B and NIST SP800-38d
section 8).
If one uses pre-shared keys and VPP is restarted, the IV counter
restarts at 0 and the same IVs are generated with the same pre-shared
keys materials.
To fix those issues we follow the recommendation from NIST SP800-38a
and NIST SP800-38d:
- we use a PRNG (not cryptographically secured) to generate IVs to
avoid generating the same IV sequence between VPP restarts. The PRNG is
chosen so that there is a low chance of generating the same sequence
- for AES-CBC, the generated IV is encrypted as part of the message.
This makes the (predictable) PRNG-generated IV unpredictable as it is
encrypted with the secret key
- for AES-CTR and GCM, we use the IV as-is as predictable IVs are fine
Most of the changes in this patch are caused by the need to shoehorn an
additional state of 2 u64 for the PRNG in the 1st cacheline of the SA
object.
Type: improvement
Change-Id: I2af89c21ae4b2c4c33dd21aeffcfb79c13c9d84c
Signed-off-by: Benoît Ganne <bganne@cisco.com>
Diffstat (limited to 'src/vppinfra/tw_timer_16t_2w_512sl.c')
0 files changed, 0 insertions, 0 deletions