<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <br>
    <div class="moz-cite-prefix">On 11/28/2017 9:34 AM, Michael StJohns
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:e29daa1d-1706-3608-1b6c-ca98ccb9810a@comcast.net">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <div class="moz-cite-prefix">On 11/28/2017 1:04 AM, Jamil Nimeh
        wrote:<br>
      </div>
      <blockquote type="cite"
        cite="mid:1e69c4c2-005a-7587-77ce-2dda634fe902@oracle.com">
        <meta http-equiv="Content-Type" content="text/html;
          charset=utf-8">
        Hi Mike, I know I said you made arguments in favor of specifying
        the keys up front in init, but I'm still really uncomfortable
        with this.  It's been bothering me all day.  Comments below:<br>
      </blockquote>
      <br>
      Before I get to those:<br>
      <br>
      1) Do you know of any protocol using a KDF where the key
      production information is not known before you'd need to call the
      .init()?<br>
    </blockquote>
    I honestly don't.  I think it's safe to say you probably don't need
    a KDF instance until you know at least the first object you want out
    of it.  But for the protocols I know of all the objects are known
    once a cipher suite or proposal is agreed upon.<br>
    <blockquote type="cite"
      cite="mid:e29daa1d-1706-3608-1b6c-ca98ccb9810a@comcast.net"> 2) If
      you do, couldn't you simply provide an empty or null list of key
      derivation spec's to .init()?<br>
    </blockquote>
    You could, but that would end up necessitating two models of
    operation.  One where we give a  list up front of all objects and
    call derive actions with no parameters, and a second model where you
    specify nothing and then provide object specs one-by-one.  Each one
    has pros and cons, but trying to support both models I think would
    make the API even more confusing.<br>
    <blockquote type="cite"
      cite="mid:e29daa1d-1706-3608-1b6c-ca98ccb9810a@comcast.net"> 3) If
      you're doing a multiobject production from a single call to
      .init() do you expect in all cases to NOT include the production
      data as mixins?<br>
    </blockquote>
    In all cases?  I can't honestly say that.  For the protocols I know
    of, the individual object attributes (like length) are not mixins. 
    But you later go on to say that you know of a couple protocols where
    they do.  If we have real-world scenarios where individual object
    lengths or other attributes really affect the keystream then I guess
    we need to take that into account.<br>
    <blockquote type="cite"
      cite="mid:e29daa1d-1706-3608-1b6c-ca98ccb9810a@comcast.net"> <br>
      My problem is that I have use cases where ALL of my key production
      information is used as mixins to the key stream.  Now I could
      provide a List<DerivationParameterSpec> as part of the KDF
      init algorithm parameter spec (kdfParams), but that means that I
      have to provide a different APS for each different key schedule
      (consider TLS1.3s various calls). If you take out the
      List<DerivationParameterSpec> out of the .init() I'll end up
      having to do that and probably having to accept null values for
      the deriveKey calls.<br>
      <br>
    </blockquote>
    <blockquote type="cite"
      cite="mid:e29daa1d-1706-3608-1b6c-ca98ccb9810a@comcast.net"> More
      in line.<br>
      <br>
      <br>
      <blockquote type="cite"
        cite="mid:1e69c4c2-005a-7587-77ce-2dda634fe902@oracle.com"> <br>
        <div class="moz-cite-prefix">On 11/27/2017 10:09 AM, Michael
          StJohns wrote:<br>
        </div>
        <blockquote type="cite"
          cite="mid:edf90ac5-4a48-28b1-505f-622511c4481c@comcast.net">
          <meta http-equiv="Content-Type" content="text/html;
            charset=utf-8">
          <div class="moz-cite-prefix">On 11/27/2017 1:03 AM, Jamil
            Nimeh wrote:<br>
          </div>
          <blockquote type="cite"
            cite="mid:7f0599a1-4aab-8c77-defe-d86120f7bbf9@oracle.com">
            <br>
          </blockquote>
          <br>
          HKDF and SP800-108 only deal with the creation of the key
          stream and ignore the issues with assigning the key stream to
          cryptographic objects.  In the TLS version of HDKF, the L
          value is mandatory and only a single object is assigned per
          init/call to the KDF.   An HSM can look at the HKDF label
          information and set the appropriate policies for the assigned
          cryptographic object (because if any of the label data
          changes, the entire key stream changes).  That's not the case
          for the raw HKDF nor for any KDF that allows for multiple
          objects to be extracted out of a single key stream.  Hence the
          per-component length values.</blockquote>
        So enforce a no-zero-length key policy in your provider code. 
        You probably can't affect the internals of the HSM, but you
        should be able to prevent it in the provider code.  I can't get
        away from the feeling that this could be dealt with in other
        ways besides specifying all this up-front.<br>
      </blockquote>
      <br>
      The best way to understand this is to look at the PKCS11 TLS1.2
      and before KDF stuff.  The key production schedule was for an
      encryption key, an integrity key and two IVs, all from the same
      key stream.  It turns out that NOTHING the HSM could do could
      prevent the extraction of key material because changing the
      boundaries between each object did not change the key stream.  In
      the TLS case (and IPSec for that matter), it's a simple matter to
      move confidential key material into non-confidential IVs. 
      However, even if you limit the production to only confidential
      items, you still have a problem in that using the same key
      material for different algorithms (e.g. using part of an AES key
      as a single DES key) can lead to vulnerabilities.<br>
      <br>
      TLS 1.3 fixed this problem by only doing single key productions
      for each call to the KDF (and by adding the length of the
      production to the mixins).  Because of this, an HSM can look at
      the mixin data and "do the right thing" with respect to policy. 
      If TLS1.3 had kept the multiple object production model, they
      would have included the per-object lengths in the KDF mixin data.<br>
      <br>
      The HSM can do the right thing because the bits it can depend upon
      (in the TLS 1.3 case the label and the length) are included in the
      mixin and not simply as part of the added on key creation stuff. 
      Without this, there is nothing an HSM can do for enforcement
      because changing these inputs wouldn't change the key stream.<br>
      <br>
      <br>
      <blockquote type="cite"
        cite="mid:1e69c4c2-005a-7587-77ce-2dda634fe902@oracle.com">
        <blockquote type="cite"
          cite="mid:edf90ac5-4a48-28b1-505f-622511c4481c@comcast.net"> 
          <br>
          <br>
          Ideally, there should be a complete object spec for each
          object to be generated that is part of the mixins (label and
          context) for any KDF.   That allows an HSM to rely upon the
          object spec when setting policy controls for each generated
          object - and incidentally allows for a KDF to generate both
          public and non-public data in a secure way.<br>
        </blockquote>
        Between different generations of keystreams do you expect to
        have different sets of policy controls?  The KDF API has no way
        for you to set those things so I would assume those would be
        pretty static, or at least controlled outside the KDF API.  If
        so, why is the KDF API concerning itself with how some HSM sets
        its policy on objects it makes?<br>
      </blockquote>
      <br>
      If I call a KDF with the same key but with different key
      productions, I *want* the key stream to be different.  If I call
      it with the same key but with same key productions, I *want* it to
      be the same.   Say I call the KDF to produce two objects -  an AES
      key of length 16 bytes and a HMAC-SHA256 key of also length 16
      bytes.  If I then call the same kdf with the same key to produce
      two AES keys of length 16 bytes (same overall length of the key
      stream, but different objects), I would *really* like it if the
      second object did not have the same key bytes as the HMAC-SHA256
      key of the first call.   The only way I can ensure this is to
      provide mixins that cause the entire key stream to change if
      anything changes in the key production data.<br>
    </blockquote>
    With the KDFs I know of I don't see how you're going to pull that
    off.  If you call HKDF with the same key, same salt, same info,
    you're going to create the same keystream, no matter how you choose
    to segment it or what kinds of objects you wish to assign them to. 
    I guess in your implementation of a KDF you can choose to go through
    the DPS objects and mix their attributes in.<br>
    <br>
    I had been working on the model that kdfParams provides the mixins
    (salt, context info, iteration count, whatever the KDF needs to make
    a keystream).  That was based on how the KDFs I know of function. 
    Even TLS 1.3 keys can be done via HDKF in this manner by just adding
    those label and length properties to the context info field.  But if
    you want your implementation to draw it from the DPS, I guess you
    could do that.  It just seems like two providers providing the same
    algorithm would come to different answers.<br>
    <br>
    <blockquote type="cite"
      cite="mid:e29daa1d-1706-3608-1b6c-ca98ccb9810a@comcast.net"> <br>
      If the mixins include policy hints (key type, key length, label,
      etc) then the HSM can rely upon those and set policy accordingly
      for the objects. <br>
    </blockquote>
    I think I alluded to that up above with TLS 1.3 key derivation using
    HKDF.  The kdfParams APS for an HKDF-Expand operation would provide
    context specific info in the form of an HkdfLabel.  You'd have the
    key-specific info you're talking about already as part of the
    mixin.  You don't need to get it from the DPS directly.<br>
    <blockquote type="cite"
      cite="mid:e29daa1d-1706-3608-1b6c-ca98ccb9810a@comcast.net"> <br>
      <blockquote type="cite"
        cite="mid:1e69c4c2-005a-7587-77ce-2dda634fe902@oracle.com">
        <blockquote type="cite"
          cite="mid:edf90ac5-4a48-28b1-505f-622511c4481c@comcast.net"> <br>
          So as long as you allow for the specification of all of the
          production objects as part of the .init() I'm good.   A given
          KDF might not require this - but I can't see any way of fixing
          the current KDFs to work in HSMs without something like this.<br>
          <br>
          <blockquote type="cite"
            cite="mid:7f0599a1-4aab-8c77-defe-d86120f7bbf9@oracle.com">As
            far as your (5) scenario goes, I can see how you can twiddle
            the lengths to get the keystream output with zero-length
            keys and large IV buffers.  But that scenario really glosses
            over what should be a big hurdle and a major access control
            issue that stands outside the KDF API: That the attacker
            shouldn't have access to the input keying material in the
            first place.  Protect the input keying material properly and
            their attack cannot be done. <br>
          </blockquote>
          <br>
          Let me give you an example.   I'm running an embedded HSM - to
          protect TLS keys and to do all of the crypto.  An attacker
          compromises the TLS server and now has access to the HSM.  No
          problem - I'm going to notice if the attacker starts
          extraditing large amounts of data from the server (e.g. copies
          of the TLS in the clear but possibly reencrypted data stream)
          so this isn't a threat or is it?  Smart attacker does an
          extraction attack on the TLS 1.2 and before KDF and turns all
          of the key stream material into IV material and exports it
          from the HSM.  The attacker now has the much smaller key
          material so he can send a few messages with those keys and
          allow for the passive external interception of the traffic and
          decryption thereof without the risk of detection of all that
          traffic being sent.  Alternately, I can place the key material
          in a picture via steganography and publish it as part of the
          server data.<br>
        </blockquote>
        "If the attacker compromises a TLS server" is the part that gets
        me...we're using external software bugs/security holes as a
        justification to make the KDF API in ways that I think are less
        clear to the consumer, to cover one class of providers (HSMs).<br>
      </blockquote>
      <br>
      This isn't a bug in the HSM - its a bug in thinking about how KDFs
      work/should work.    There are three parts to a KDF - extraction
      of entropy from the master secret, expansion of that entropy into
      a key stream and finally, assignment of that key stream to
      cryptographic objects.  HKDF and SP800-108 talk about the first
      two, but don't consider the implications of the third.   Because
      of this, neither TLS1.2 nor IPSec provide a KDF with secure key
      production.<br>
    </blockquote>
    When I referred to "bug" I wasn't talking about the HSM, I was
    referring to the server that could be compromised, but no matter. 
    I'm not sure there's any KDF API out there that talks about the
    third class.  Seems like they're all concerned with providing the
    first two.  I had envisioned our KDF API providing equivalent
    functionality.<br>
    <blockquote type="cite"
      cite="mid:e29daa1d-1706-3608-1b6c-ca98ccb9810a@comcast.net"> <br>
      <br>
      <blockquote type="cite"
        cite="mid:1e69c4c2-005a-7587-77ce-2dda634fe902@oracle.com">
        <blockquote type="cite"
          cite="mid:edf90ac5-4a48-28b1-505f-622511c4481c@comcast.net"> <br>
          The idea is to protect extraction of the key material from an
          HSM <u><b>even from authorized users of that key material</b></u>. 
          <br>
        </blockquote>
        That may well be a goal for the HSM, to be solved by the HSM or
        the provider that front-ends it.  I do not see that as something
        to be solved by the KDF API.<br>
      </blockquote>
      <br>
      It has to be solved by the KDF API because the only way this works
      is if the mixin data for all the productions is included prior to
      producing the first object.<br>
      <br>
      <blockquote type="cite"
        cite="mid:1e69c4c2-005a-7587-77ce-2dda634fe902@oracle.com">
        <blockquote type="cite"
          cite="mid:edf90ac5-4a48-28b1-505f-622511c4481c@comcast.net"> <br>
           KDFs don't currently do this well.  Adding the overall length
          and per component length stuff as well as a per component spec
          to the data used to derive the key stream means that 1)
          changes to any of those change the entire key stream, 2) the
          per component spec data may be used by the security module
          policy engine to enforce restrictions and 3) because of (1)
          and (2) calling the KDF a second time gets me exactly the same
          objects rather than just the same key stream.  The last isn't
          very important in a software based security domain, but turns
          out to have real implications for policy enforcing security
          modules.<br>
        </blockquote>
        But there aren't KDFs that take individual component lengths as
        inputs, so alterations to individual key component lengths don't
        change the keystream (unless someone decides to write a KDF that
        does, but none that I've seen do).  With the way the KDF API is
        taking shape, there's no enforcement that you get the same
        objects - none of that is locked to the instance.  It can change
        between inits.  If you reinitialize with the same key and KDF
        parameters, whether you specify all objects up front or one at a
        time in derive calls you can still ask for a different set of
        output objects.  And changing lengths on various objects won't
        matter because HKDF, Counter-mode KDF, Feedback-mode KDF...none
        of those care a whit about individual component lengths.  All
        they care about is the total length of the keystream (and HKDF
        only cares about that to make sure it's not more than 255 * Hmac
        length).<br>
      </blockquote>
      Yes but.<br>
      <br>
      TLS1.3 will be NOT be an HKDF KDF instantiation, it will be a
      TLS1.3 KDF instantiation (which uses the HDKF function internally)
      that will limit production to a single object per init and with a
      known set of labels and using L as a mixin.  Because that's how
      TLS13 dealt with the problem.<br>
      <br>
      AND - there are KDFs that take individual components lengths as
      inputs - in at least two proprietary protocols that I know of. 
      Mostly though, with the trend to AEAD algorithms most of the
      protocols are tending to move to a single production per init.
      (since they don't need both an integrity and confidentiality key
      nor an IV per se)<br>
    </blockquote>
    <blockquote type="cite"
      cite="mid:e29daa1d-1706-3608-1b6c-ca98ccb9810a@comcast.net"> <br>
      <br>
      <blockquote type="cite"
        cite="mid:1e69c4c2-005a-7587-77ce-2dda634fe902@oracle.com">
        <blockquote type="cite"
          cite="mid:edf90ac5-4a48-28b1-505f-622511c4481c@comcast.net"> <br>
          This gets worse when you realize that the KDF key is under it
          all either a HASH HMAC or CMAC key and all of those algorithms
          produce public data.   Ideally you need a way of preventing a
          KDF key from calling the raw HASH/HMAC/CMAC functions directly
          (and vice versa).<br>
        </blockquote>
        I don't see how we'd prevent this in software.  If I've got a
        key as input to a KDF (a SecretKey) there's no way to prevent it
        being used by anything else that takes a SecretKey.  If you need
        to prevent that in hardware then that seems like a concern for
        your provider or the HSM itself.<br>
      </blockquote>
      <br>
      If I tag a key as MasterSecret (where MasterSecret is not a
      subinterface of SecretKey, but is of Key) and use MasterSecret
      instead of Key in .init().....<br>
      <br>
      The HSM (and the JVM) would both identify functions that can be
      used with that key and keep others away.<br>
      <br>
      This is what I was talking about with cryptographic type safety in
      my last email - the idea that the Key objects be as strongly typed
      as possible to prevent them from being used inappropriately or in
      ways that mathematically bypass security.   Take a KDF with a PRF
      of CMAC-AES-128.  The KDF is meant to produce secret data (a key
      stream for the production of keys), but a CMAC-AES-128 is meant to
      produce public data (an integrity tag over a set of data).  Given
      that KDF algorithm is simply a wrapper to the PRF to allow for the
      production of multiple blocks of data, then its trivial - if you
      have access to *use* the KDF key - to use it with the CMAC
      function to extract the key stream.<br>
      <br>
      In the HSM I can *somewhat* combat this by (in PKCS11) attributing
      the key, but how do get those attributes on the key in the first
      place if I'm using a Java front end?<br>
      <br>
      In software this isn't a big thing as the confidential key
      material and the public CMAC integrity tag are both in the same
      software domain.  But over the years we've tried to do the right
      thing (see javax.security.auth.Destroyable for example) by
      thinking about security past the limitations of what we can get in
      software.<br>
      <br>
      For KDFs I'd add a  jaxa.crypto.MasterSecret interface extending
      Key,Destroyable (and pretty much a clone of SecretKey) a
      javax.crypto.spec.MasterSecretSpec implementing KeySpec and
      MasterSecret (and a clone of SecretKeySpec) to tag these secret
      keys as for use only with a KDF.<br>
      <br>
      Mike<br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <p><br>
      </p>
    </blockquote>
    <br>
  </body>
</html>