IBM Crypto Education Community

IBM Crypto Education Community

IBM Crypto Education Community

Join the IBM Crypto Education community to explore and understand IBM cryptography technology. This community is operated and maintained by the IBM Crypto Development team.

 View Only
  • 1.  Master keys sharing

    Posted 11/17/20 10:13 AM
    Dear ,

    Basic but important question :
    ---------------------------------

    Is it possible to share a generated/loaded Master Key of a domain index(1) in another domain index(2) ?
    For example :
    If we have an Lpar1 in domain index(1) and  Lpar2 in domain index(2) . Is it possible to generate the Master key1 for the Lpar1 in domain index(1) and insert this Master key1 for  Lpar2 in the domain index(2) ?

    And then , by extension can we use the same Master key in different domain for different Lpars ?

    What are the eventual consequences of that (restrictions ? cons ? limits ?)

    Thanks in advance .
     



    ------------------------------
    Nordine Mosbah
    ------------------------------


  • 2.  RE: Master keys sharing

    Posted 11/17/20 12:25 PM
    Hi,
    Most customers enter a Master Key by key parts where : 2 or more non-zero key parts are used,  knowledge of 1 key part is limited to a designated security officer and backup in their organization, no single person is primary or backup on knowledge of more than 1 key part.  As I am sure you are aware, knowledge or control of all parts of the Master Key by 1 person has led to trouble in the industry, cases can be found readily by Google search.   With the above manual controls it is a simple matter to enter the same Master Key to multiple domains, coordinated/secured access.
    The Trusted Key Entry workstation (TKE) makes all of this much easier and adds a layer of security: smart cards can be used to store the key parts.  Using a TKE also allows you to load the key parts using dual control processes and commands signed by the security officer holding the key part. The TKE can also configure domain and HSM groups to simplify Master Key load further.  A further function of the TKE is the migration wizard, which allows you to pull all configuration from 1 HSM or 1 domain of 1 HSM and apply that securely to another HSM, based again on the properties of dual control so that no single participant in the migration has control of the Master Key and other configuration data when it is outside of the HSM.
    Hope this helps and please come back with any further questions!

    ------------------------------
    Richard Kisley
    ------------------------------



  • 3.  RE: Master keys sharing

    Posted 11/18/20 08:28 AM
    Hi ,

    We would like to use Crypto Express6S cards in a first time whitout TKE workstation but in a few time (not right now) one little part of of ours systems would use a future TKE .
    So then , to satisfy this combined need I supposed then than the adapters (already installed) can stay configured in a CCA Coprocessor mode , isn't it ? (I imagined yes)

    Meaning , that this CCA coprocessor mode allow the usage of one systems part managed by TKE and another one without (ICSF panels) , is this possible ?
    For info , The systems are spread in differents z servers and the reason of not regrouping them all in TKE is purely management :)- 

    Thanks .

    ------------------------------
    Nordine Mosbah
    ------------------------------



  • 4.  RE: Master keys sharing

    Posted 11/18/20 10:28 AM
    Hi,
    Yes, that usage can be intermixed on the same CCA coprocessor (HSM) in coprocessor mode.  The system is designed to be flexible according to your needs.  As you start administering domains with the TKE you will see the CCA access control system.  The CCA access control system has 'roles' and 'profiles'.  A 'profile' is a user identity that maps to a key associated with a particular user.  A 'role' is a set of capabilities called 'access control points'.  Each 'access control point' limits or opens a particular set of function on the HSM.  Usually a given user 'profile' will designate a 'role' with the set of capabilities that apply for that user.  From TKE you will load unique administrative roles and profiles to administer each domain of the adapter - preparing for an HSM-authenticated access control model; the public key in the profile is used by the HSM to check the signature on administrative commands.  As noted this can be simplified with group management, however the system allows the flexibility for a given domain or set of domains to have different administrative users.  PCI-HSM mode further enhances domain separation and dual control requirements.

    On IBM Z there is a 'default role' that is in force on each domain, not mapped to any profile.  This is the set of capabilities that you exploit from the LPAR or z/VM instance with your application. The 'default role' has 'access control points' enabled that allow you to set the Master Key from the ICSF panel along with many other function sets.  Typically users set up host-authenticated controls through RACF or another tool to ensure that operations like Master Key load are only usable by certain users.

    When you start administering some domains with the TKE you may want to disable the 'access control points' in the 'default role' that allow Master Key set from the ICSF panel.  This change to close the host-authenticated channel would reflect the greater security requirement  for those domains that have moved to TKE and HSM-authenticated management.

    ------------------------------
    Richard Kisley
    ------------------------------