Audit and Assurance

Expand all | Collapse all

HSM Key Management and Key Life/ Period

  • 1.  HSM Key Management and Key Life/ Period

    Posted 01 Mar, 2020 18:44
    Dear All,

    Just to set the context,

    All of we know that the PCI DSS and PCI 3DS has specific requirement for HSM to protect and manage the Key life cycle. While following and addressing the requirement, I have personally observed that the auditors do ask for Key Life Cycle or Crypto Period.

    Basically as per my understanding the requirement and context to set the crypto period is, to know and avoid the possibility of encryption/decryption logic getting exposed or the possibility of encryption logic getting weak over the period.

    On this my opinion is as follows and I request my colleague /Peers /Seniors to share their views.

    Basically the requirement of Crypto period is more relevant and should get followed strictly when the key are being used on Web layer which is exposed to web/ Internet and there the concern of possibility of keys getting exposed is more relevant as Public keys anyway are exposed and data mining is possible and proven to happen to get the private Keys.

    but in the context of the HSM keys, where there is no exposure to the internet, SOD in place and  having controls such as

    1) dedicated HSM administrator (having zero knowledge of HSM password),
    2) HSM login Password in with key custodians (with split knowledge),
    3) Only key custodians do key loading and aware about keys (Two or Three custodians with split knowledge, as per PCI DSS / 3DS requirement)
    4) Also the internal VLAN segmentation is in place, allowing only APP servers or HSM Controllers with Dual SSL authentication in place.

    How fruitful it is to change the keys or set the Crypto period?

    Also, there could be business challenges such as,

    1) While decrypting the data and encrypting with new Key I may not be able to serve the transaction even though the secondary site is in place.
    2) This shall attract 100% downtime for the business and activity can't be scheduled with specific timelines, considering the data size for decryption and encryption activity.

    These are my view and I again request my colleague/ Peers / Seniors to share their views and suggest if any practices are in place to replace HSM keys without downtime or how to address this point in better way, if any.

    All your inputs are highly appreciated.

    D Anand

  • 2.  RE: HSM Key Management and Key Life/ Period

    Posted 01 Mar, 2020 19:39
    Hi Anand,

    When dealing with cardholder data and other topics that relate to the various PCI standards, you're better off talking to someone qualified, e.g.someone who is certified by the PCI Security Standards Council on the particular standards in question, rather than asking a general auditing community -- which may give you the wrong answer, as PCI standards are generally control-based, not risk based.

    That being said, I am both a PCI QSA and PCI 3DS Assessor, and while I am not *your* assessor, I am happy to answer your questsions.

    You are correct in noting that both PCI DSS and the PCI 3DS standards require the entity to have documented policies and procedures related to the determination and enforcement of cryptoperiods. Those periods are required to be set in accordance with industry standards (which for PCI generally means NIST standards).

    The purpose of setting a cryptoperiod is to ensure that encryption keys used to protect card account data are changed before they have been used too many times. This has nothing to do with the encryption/decryption logic being exposed -- in fact, the logic (cryptographic algorithms) are public and well-known. Additionally,the certainty of encryption logic (algorithms) getting weak over time has nothing to do with the cryptoperiod -- that particular certainty is dealt with through the retirement and replacement of approved cryptographic algorithms. For example, TDEA used to be acceptable for the protection of stored CHD, but was disallowed some years ago per NIST SP 800-57.

    For a discussion of, and recommendations for, the setting of cryptoperiod length, see NIST SP 800-57.

    There is zero impact from changing keys on HSMs in accordance with their cryptoperiods. Key change functionality is built in to HSMs , and there is no reason for the downtime you've suggested. In fact, in many circumstances, there is no need to even re-encrypt stored data; if the crypto period has been set appropriately, the old key can continue to be used -- solely for decrypting already encrypted data, while any new data is encrypted with the new keys -- again, all per NIST SP800-57 and various PCI requirements.

    Finally, many of the HSM controls that you mentioned are required by PCI DSS, PCI 3DS (as well as PCI PIN, PCI P2PE etc.) for other reasons. Dual control of HSMs is required in order to ensure that a single individual cannot generate keys or change configuratons.

    Split knowlege of plaintext key components, when used, in order to prevent a signle individual from having any knowledge of a key or part of a key, is required. And that means full-length key components, by the way, e.g., if the key is 256 bits, all components must be 256 bits as well.

    While VLAN segmentation is not always required, most of the PCI standards do require that the HSM APIs be able to be accessed only from specified sources in order to prevent, for example, an attacker who managed to obtain access to encypted CHD and the encrypted DEK from being able to pass them into the HSM to decrypt the CHD.

    As I mentioned, you are best off consulting with someone who is PCI SSC certified on the standards you're working with. Most of the time, that would be your QSA, although some companies will have another QSA company that they use for "advice" consulting, and only use their assessor for assessment/audit.

    The company I work at is not only a PCI QSAC, but also certified under virtually all of the PCI SSC programs, including PFI. Let me know if you're interested in an advisory consulting engagement at

    Best regards,



    ✉️  |��

    Any views or opinions contained in this communication are solely those of the author, and do not necessarily represent those of any organizations or entities the author may be associated with.

  • 3.  RE: HSM Key Management and Key Life/ Period

    Posted 01 Mar, 2020 19:58
    Edited by Anand D 01 Mar, 2020 20:00
    Hi James,

    Thanks for your inputs,

    As your rightly pointed out, Crypto period is nothing to do with encryption/decryption logic and to ensure that those gets changed in time.

    Sorry I could not able to set here in a right manner. As per the industry standard 3 year is the time which set to be ideal as crypto period, what is the timeline do you suggest.

    A company being service provider, it is a task to keep keys rotating and being QSA you better know when key management and change is required its not only about the DEK there are other components which are related needs to get replaced.

    I have also noted the point which you have mentioned as advisory however the point which I have raised is in generic in nature and not specific to me but shall connect you offline on this.

    Thanks again!

    D Anand