Traditional Approaches

Where the direct use by a device of dedicated security hardware is not appropriate or available, there are two general approaches to ensuring the security and control of stored values such as cryptographic keys. These are Local or Centralised Key Storage...

The first concerns storing keys locally. Where they are protected (or encrypted) using a password, then there are two common approaches, one being to use a login password to make keys available to applications (possibly not just the intended application) on the device, the other is to use a password when the key is required. The problem with this type of approach is that protection is only as good as the password employed, and so the keys are vulnerable to attacks such as an exhaustive search on the password. If stored keys are to be protected by being encrypted with a full strength encryption key, then all you have really achieved is to redefine the problem of how to protect one set of keys with how to protect another (similar) set of keys.

  • Advantages: Users have full ownership and control over their keys
  • Disadvantages: Vulnerable to compromise by accessing or analysing the content of the device, and if protected by a password then reliant on the password strength

The other approach is to store keys in a centralised server or service, often employing a HSM (Hardware Security Module) for physical protection. Sometimes all keys are stored centrally, sometimes it is just a master key that is used to decrypt other keys as necessary.

  • Advantage: Centralised management
  • Disadvantages: Effectively entrusting keys to another party, and concentrates all security and trust in one place thereby creating a single point of failure - sometimes referred to as 'all eggs in one basket'

A new approach from SEAcurIT-e

SEAcurIT-e fills the gap between these two approaches. It gives the best of both worlds, whilst eliminating the disadvantages.

  • No information about keys can be obtained by analysing the key storage-related information resident on a device.
    • Doesn't entrust the secrecy of keys to another party
    • Computationally infeasible for any system element to derive any information about keys or other security values, even if a user's password is known.
    • No system information that can be used as basis to compromise user passwords such as exhaustive search, irrespective of the strength of the password
  • No secrecy impact if element is compromised
  • No single point of failure, where the distributed nature of system as security ensures that secrecy remains protected even if every system component is compromised
  • Gives the benefits of centralised management and control but without entrusting the secrecy of keys to another party
  • Assumes that any part of system may be compromised, and ensures that keys are protected