|
The encryption keys that form the basis of all secure and/or authenticated IPsec communication are exchanged over a secure channel once the identity of the opposite endpoint has been verified. One of two mechanisms can be used to perform this verification:
1) A pre-shared key (PSK) can be configured on both endpoints
2) Asymmetric encryption keys can be exchanged automatically using cryptographically signed X.509 certificates
In the first scenario, the fact that the other party is in possession of the same key is seen as proof that you're communication with the right host. In the second scenario you're relying on a certificate issued by a third-party CA, and the signature of that CA is considered proof that the CA has validated the identity of the certificate holder. No data can be encrypted or signed before the key or certificate has been validated.
In both cases, the key(s) in question are not used for encrypting data; random session keys are generated and replaced at regular (configurable) intervals. It is possible for an application to override this mechanism and specify the encryption key to be used. This is hardly ever done (for obvious reasons).
IPsec does not provide a mechanism for key storage and management; it's up to the IPsec implementation to store pre-shared keys. Certificates are exchanged automatically, so the only certificate one needs to store is one's own. Again, it's up to the IPsec implementation to access a certificate store provided by the OS or an application, or it could have its own store.
|
