9

Are there formal security definitions or frameworks to evaluate the quality of a key management scheme? Can I state something like "the key is XYZ-protected against a polynomial adversary given that [constraint] holds"? Or "that solution has a key exposure factor of 0.72"?

For example, I can intuitively see that a key that is secret shared has better protection than a key that is not (because, for a threshold t, t shares would need to be compromised to calculate the key). Or that a key inside an HSM is harder to retrieve than a key in a plaintext file in a PC. But how harder?

How can I objectively argue that a control is critical to protect the key (or the opposite: that discarding a specific control is acceptable in a scenario)?

I realize that a definitive answer will depend on the threat model and the risks that could be accepted, but I wonder if there are terms and parameters that can be used to compare alternatives.

  • There are several well-known standards, security policies, regulations for crypto-graphic key management. Is that what you are looking for? – Ubaidah Mar 25 '16 at 19:42
  • 1
    And usually they put a lot of emphasis on their FIPS 140/Common Criteria certifications. What I am wondering is if there is to build a more solid argument than "it is an industry standard, and therefore it is good" (I feel it too close to a falacy). For instance, if I were to say "store a key in a smart card of (specific model) is as safe as storing it in an HSM (specific model)" could there be better reasons than "both are FIPS 140 level 3 certified"? I feel certifications please managers, but leave technical people with some level of doubt. – Sergio Andrés Figueroa Santos Mar 26 '16 at 8:57
  • 1
    There are various methodologies for quantitative risk assessment (e.g. this). I am pretty sceptical about their usefulness; in infosec there are so many unknowns. Also, you are estimating a "long tail" of unlikely events, so small uncertainties have a large impact. I would advise you to use a qualitative methodology instead. Start by thinking about what realistic options you have for key storage. – paj28 Mar 28 '16 at 12:44
  • 2
    @SergioAndrésFigueroaSantos: You are right about the FIPS 140 doubt part. USB-Sticks had been tested and certified for FIPS140 ... but only for the implementation of the crypto-algorithm. They did not certify the USB-Sticks as a whole. Result: FIPS140-Sticks send the same 32 bytes after a sucessful login ... making them very easy to crack by sending those 32 bytes yourself. Therefore certifications or absolute numbers (as proposed here) make little sense, since they wont reflect the whole picture imho. – hamena314 Mar 30 '16 at 13:45
  • 1
    Sounds about right - and a little bit sad. But I think it won't be possible to create an "additive list" that contains things adding to security. I.e. "HMS +1, FIPS 140 certified +0.75, ...". It should be more like: "Is the system secure?" and if you find a flaw the answer is "No". If you want to have more degrees of security, you could create a "Probability / Impact"-graph: How probable is a certain attack or error to occur and how big would the impact be? If an attack is very unlikely and has a low impact: ignore. If the attack is very likely and has a high impact: system is flawed. – hamena314 Mar 31 '16 at 7:47
1

I doubt if there will be a nice answer to this question. There are formal methods (formal verification tools) that you can validate whether your protocol satisfy some properties under some assumptions. Thus, you can mark your (key management) protocol safe. Still, you have three question remain. (1) What were the assumptions? (2) Is the model I tested really map the actual key management protocol? (3) Even in that case, is the verification tool safe, correct and sound?

Even after formal verification, you generally end up with binary results such as safe/unsafe.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.