[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [KEYPROV] MAC key support in PSKC
Hi Yehuda,
Thank you very much for your prompt input and the information about the paper.
I am looking into the link and discussing it with a few others. I will follow up
with you more on this in a day or two.
- Ming
> -----Original Message-----
> From: Andrew Lindell [mailto:Andrew.Lindell at aladdin.com]
> Sent: Sunday, May 03, 2009 6:27 AM
> To: Pei, Mingliang; Doron Cohen; Philip Hoyer; Salah Machani;
> keyprov at ietf.org
> Subject: RE: MAC key support in PSKC
>
> Hi Ming,
>
> The concern that you raise regarding a man-in-the-middle
> attack is infeasible because it requires forging a MAC, which
> is exactly what MACs are there to prevent. (I'm also assuming
> that you have a typo; the attacker would have to guess the
> random K_MAC key to set a matching encrypted MAC value, not
> the encryption key KEK.)
>
> Coming back to computing the MAC over the secret K directly
> and then encrypting the key together with the MAC. I stress
> that I am not claiming a problem with the proposed modes
> (indeed AES-128-CBC has been proven to be secure under this
> mode; see
> http://www.iacr.org/archive/crypto2001/21390309.pdf) Now,
> although I don't know of any problem with KW-AES-128 in this
> mode (and I would be very surprised if there were a problem),
> I KNOW that it is secure when you apply the MAC to the
> ciphertext. Furthermore, I know that it will ALWAYS be secure
> for any secure encryption method. Thus, I strongly prefer to
> apply the MAC to the ciphertext and be sure that we will
> never fall into a trap.
>
> I therefore do think that it's better to apply the MAC to the
> ciphertext.
>
> All the best,
>
> Yehuda
>
> ________________________________
>
> From: Pei, Mingliang [mailto:mpei at verisign.com]
> Sent: Fri 5/1/2009 9:31 PM
> To: Andrew Lindell; Doron Cohen; Philip Hoyer; Salah Machani;
> keyprov at ietf.org
> Subject: RE: MAC key support in PSKC
>
>
> Hi Yehuda,
>
> Thank you for your comment. Good to know your native first name.
>
> The concern is that knowing both the MAC value of the secret
> K and cipher value of K may combine to lead to a hole someway
> depending on MAC and encryption algorithm. Because the K_MAC
> itself is random and independent of KEK, it looks to me that
> collision is remotely possible. The overall security strength
> lies in the individual MAC algorithm and encryption algorithm
> themselves and the strength of the KEK. We can always
> recommend that a proper MAC algorithm and encryption
> algorithm are used today and future. Currently, the MAC
> algorithm can be HMAC-SHA256 or CMAC-AES-128 and the
> encryption algorithm can be KW-AES-128 and AES-128-CBC etc. I
> think that we can achieve this in future algorithm choice too.
>
> If we choose MAC over ciphertext, a risk is that a
> man-in-the-middle may set its own ciphertext value and
> corresponding MAC to the field. If this is successful, a
> receiver would extract a bad secret that isn't sent by the
> original sender. The risk isn't high though because the
> attack needs to guess encryption key KEK to set a matching
> encrypted MAC value.
>
> I would like to get your assessment input on this risk. How
> do you consider it in comparison with the proposed approach?
> Do you think that it is better if the recommendation is
> changed to apply MAC on the ciphertext? Thanks,
>
> - Ming
>
>
> ________________________________
>
> From: Andrew Lindell [mailto:Andrew.Lindell at aladdin.com]
> Sent: Wednesday, April 29, 2009 11:00 PM
> To: Pei, Mingliang; Doron Cohen; Philip Hoyer; Salah
> Machani; keyprov at ietf.org
> Subject: RE: MAC key support in PSKC
>
>
>
> Hi Ming,
>
>
>
> Choosing a separate random MAC key alleviates my main
> concern, of course.
>
>
>
> I'm still not too happy that the MAC is applied to the
> plaintext and then encrypted, but we have already discussed
> this. I agree with you that there is no specific problem
> here. My concern is that the method - in general - is not
> sound, and so in the future when changing algorithms etc.
> there is no guarantee that a hole won't be opened up.
>
>
>
> All the best,
>
>
>
> Yehuda (Andrew)
>
>
>
> From: Pei, Mingliang [mailto:mpei at verisign.com]
> Sent: Wednesday, April 29, 2009 05:12
> To: Andrew Lindell; Doron Cohen; Philip Hoyer; Salah
> Machani; keyprov at ietf.org
> Subject: MAC key support in PSKC
>
>
>
> According to our online and offline discussions in this
> topic, we feel that we can come to the following proposal for
> MAC key support in PSKC:
>
>
>
> 1. MAC key will be randomly generated data and passed
> in PSKC XML in an encrypted form. The encryption uses the
> same encryption key and method as that for OTP secret.
>
>
>
> This is selected over key derivation for it can handle
> all three key protection profiles: password based, preloaded
> symmetric key, and transport profile with a RSA key.
>
>
>
> 2. MAC key material can be passed in two ways:
>
>
>
> a. it is included along with MAC algorithm.
>
> b. it is passed along with the target secret key in a
> concatenated form before the result is encrypted and set in
> the element <Key>/<Data>/<Secret>. In other words, the
> key.secret.plaintext = K_MAC || key.secret and the combined
> value is encrypted. This is used to support the way that
> DSKPP protocol sets a random K_MAC.
>
>
>
> 3. The same MAC key and algorithm will be used by all
> key packages in a KeyContainer if it contains more than one
> key package.
>
>
>
> Schema:
>
>
>
> <xs:complexType name="KeyContainerType">
> <xs:sequence>
> <xs:element name="EncryptionKey"
> type="ds:KeyInfoType" minOccurs="0"/>
> <xs:element name="MACMethod"
> type="pskc:MACMethodType" minOccurs="0"/>
> <xs:element name="KeyPackage"
> type="pskc:KeyPackageType" maxOccurs="unbounded"/>
> <xs:element name="Signature" type="ds:SignatureType"
> minOccurs="0"/>
> <xs:element name="Extensions"
> type="pskc:ExtensionsType" minOccurs="0" maxOccurs="unbounded"/>
> </xs:sequence>
> <xs:attribute name="Version" type="pskc:VersionType"
> use="required"/>
> <xs:attribute name="id" type="xs:ID" use="optional"/>
> </xs:complexType>
>
> <xs:complexType name="MACMethodType">
> <xs:sequence>
>
> <xs:choice>
> <xs:element name="MACKey"
> type="xenc:EncryptedValue" minOccurs="0"/>
> <xs:element name="MACKeyReference"
> type="xs:string" minOccurs="0"/>
> </xs:choice>
> <xs:any namespace="##other" processContents="lax"
> minOccurs="0" maxOccurs="unbounded"/>
> </xs:sequence>
>
> <xs:attribute name="Algorithm" type="xs:anyURI"
> use="required"/>
> </xs:complexType>
>
> where
>
>
>
> MACKey: the element carries the encrypted MAC key K_MAC.
>
> MACKeyReference: the value is set to the KeyID of the
> KeyPackage inside which the K_MAC was combined with key
> secret before encryption.
>
>
>
> If both are absent, the first KeyPackage is assumed to
> contain the MAC key in its encrypted secret field.
>
>
>
> Example:
>
>
>
> <?xml version="1.0" encoding="UTF-8"?>
> <KeyContainer Version="1"
> xmlns="urn:ietf:params:xml:ns:keyprov:pskc"
> xmlns:ds="http://www.w3.org/2000/09/xmldsig
> <http://www.w3.org/Web/2000/09/xmldsig> #"
> xmlns:xenc="http://www.w3.org/2001/04/xmlenc
> <http://www.w3.org/Web/2001/04/xmlenc> #">
> <EncryptionKey>
> <ds:KeyName>Pre-shared-key</ds:KeyName>
> </EncryptionKey>
> <MACMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1
> <http://www.w3.org/Web/2000/09/xmldsig#hmac-sha1> ">
>
> <MACKey>
>
> <EncryptedValue>
> <xenc:EncryptionMethod
> Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/
> <http://www.w3.org/Web/2001/04/xmlenc#aes128-cbc> >
> <xenc:CipherData>
>
> <xenc:CipherValue>MTIzNDU2Nzg5MDEyMzQ1Njc4OTA=</xenc:CipherValue>
> </xenc:CipherData>
> </EncryptedValue>
>
> </MACKey>
>
> </MACMethod>
> <KeyPackage>
>
> ...
> <Key KeyId="12345678"
> KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
>
> ...
> <Data>
> <Secret>
> <EncryptedValue>
> <xenc:EncryptionMethod
> Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/
> <http://www.w3.org/Web/2001/04/xmlenc#aes128-cbc> >
> <xenc:CipherData>
>
> <xenc:CipherValue>pgznhXdDh4LJ2G3mOY2RL7UA47yizMlXX3ADDcZd8Vs=
> </xenc:CipherValue>
> </xenc:CipherData>
> </EncryptedValue>
>
> <ValueMAC>zdrZbGBj9BDZJzunbfAG3kyZyYc=</ValueMAC>
> </Secret>
>
> ...
> </KeyContainer>
>
>
>
> <?xml version="1.0" encoding="UTF-8"?>
> <KeyContainer Version="1"
> xmlns="urn:ietf:params:xml:ns:keyprov:pskc"
> xmlns:ds="http://www.w3.org/2000/09/xmldsig
> <http://www.w3.org/Web/2000/09/xmldsig> #"
> xmlns:xenc="http://www.w3.org/2001/04/xmlenc
> <http://www.w3.org/Web/2001/04/xmlenc> #">
> <EncryptionKey>
> <ds:KeyName>Pre-shared-key</ds:KeyName>
> </EncryptionKey>
> <MACMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1
> <http://www.w3.org/Web/2000/09/xmldsig#hmac-sha1> "/>
>
> <KeyPackage>
>
> ...
> <Key KeyId="22345678"
> KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#hotp">
>
> ...
> <Data>
> <Secret>
> <EncryptedValue>
> <xenc:EncryptionMethod
> Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/
> <http://www.w3.org/Web/2001/04/xmlenc#aes128-cbc> >
> <xenc:CipherData>
>
> <xenc:CipherValue>qw2ewasde312asder394jwfdauiiowujfpouipgznhXd
> Dh4LJ2G3mOY2RL7UA47yizMlXX3ADDcZd8Vs=</xenc:CipherValue>
> </xenc:CipherData>
> </EncryptedValue>
>
> <ValueMAC>zdrZbGBj9BDZJzunbfAG3kyZyYc=</ValueMAC>
> </Secret>
>
> ...
> </KeyContainer>
>
>
>
> Comments? Thanks,
>
>
>
> - Ming
>
>
>
> ________________________________
>
> From: Andrew Lindell
> [mailto:Andrew.Lindell at aladdin.com]
> Sent: Sunday, March 29, 2009 9:37 PM
> To: Pei, Mingliang
> Cc: Doron Cohen
> Subject: RE: [OATH Technical] FW: [KEYPROV]
> WGLC: draft-ietf-keyprov-pskc-02.txt
>
> Dear Ming,
>
>
>
> Either of the approaches are fine in my
> opinion. I also agree with Hugo that this is a good
> derivation function.
>
>
>
> Thanks,
>
>
>
> Andrew
>
>
>
> From: Pei, Mingliang [mailto:mpei at verisign.com]
> Sent: Saturday, March 28, 2009 04:42
> To: Andrew Lindell;
> oath_technical at v2.listbox.com; keyprov at ietf.org
> Cc: Doron Cohen
> Subject: RE: [OATH Technical] FW: [KEYPROV]
> WGLC: draft-ietf-keyprov-pskc-02.txt
>
>
>
> Hi Andrew,
>
>
>
> Yes, we thought of using key derivation to
> obtain two keys from some discussions this week in IETF. The
> option to derive a MAC key from KEK itself is considered not
> a choice because in principle we don't want to use the same
> key for two purpose - encryption and derivation. Treating
> pre-shared key as a master key to derive KEK and K_MAC is a
> feasible choice.
>
>
>
> When two key derivation is chosen, we would
> need to define KDF in PSKC, handling both password derived
> key and pre-shared master key. For password derived key,
> maybe we can use the same derivation function but different
> salts respectively for KEK and K_MAC. It is under discussion.
> Using a different KDF for pre-shared master key may add more
> complexity than the random chosen K_MAC. The KDF could be
> simply HMAC of K_master with some different constant string
> for KEK and K_MAC, for example, KEK = HMAC(K_master, "0000")
> and K_MAC = HMAC(K_master, "1111"), thanking Hugo Krawczyk
> for the suggestion. Alternatively PSKC can easily pass
> encrypted K_MAC with KEK in payload.
>
>
>
> I favor more the random chosen K_MAC for now
> than the KDF approach for two keys in terms of one approach
> for both password and pre-shared key case. KDF is good that
> it doesn't need to pass additional parameter in payload.
> Comments are appreciated on the choice and best practices in
> other specifications.
>
>
>
> Thank you,
>
>
>
> - Ming
>
>
>
> ________________________________
>
> From: Andrew Lindell
> [mailto:Andrew.Lindell at aladdin.com]
> Sent: Monday, March 23, 2009 11:13 PM
> To: Pei, Mingliang;
> oath_technical at v2.listbox.com; keyprov at ietf.org
> Cc: Doron Cohen
> Subject: RE: [OATH Technical] FW:
> [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt
>
> Hi Ming,
>
>
>
> Thank you for your response. One thing
> however is not clear to me now. Is the hashed key (ValueMAC)
> encrypted together with the key? If yes, then I agree with
> you that it's not really a concern. This also solves the
> problem of integrity (albeit not cryptographically, where a
> MAC is really needed). However, if the hashed value is not
> encrypted, then this can be a problem if someone uses a
> procedure that results in a relatively low entropy key.
> Although such a procedure within itself is bad, this would
> make it worse and so it would be better to encrypt the hashed
> value as well.
>
>
>
> One other thing, regarding item (1).
> When two keys cannot be provided, have you thought of using
> key derivation to obtain two keys from the one. Although you
> keep the same entropy, this is more cryptographically sound
> than using the same key for both tasks.
>
>
>
> Thanks,
>
>
>
> Andrew
>
>
>
> From: Pei, Mingliang [mailto:mpei at verisign.com]
> Sent: Tuesday, March 17, 2009 04:29
> To: Pei, Mingliang;
> oath_technical at v2.listbox.com; keyprov at ietf.org
> Cc: Andrew Lindell
> Subject: RE: [OATH Technical] FW:
> [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt
>
>
>
> Copying keyprov mailing list... - Ming
>
>
>
> ________________________________
>
> From: Pei, Mingliang
> Sent: Monday, March 16, 2009 7:26 PM
> To: Pei, Mingliang;
> 'oath_technical at v2.listbox.com'
> Cc: 'Andrew Lindell'
> Subject: RE: [OATH Technical]
> FW: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt
>
> I need to clarify that the
> strong hash is good when the cleartext to be encrypted is
> some long random secret bytes. If the value is within some
> known finite integer values, some simple hash lookup over all
> possible values will reveal the cleartext itself.
>
>
>
> Thanks,
>
>
>
> - Ming
>
>
>
> ________________________________
>
> From: Pei, Mingliang
> Sent: Monday, March 16,
> 2009 7:22 PM
> To:
> oath_technical at v2.listbox.com
> Cc: Andrew Lindell
> Subject: RE: [OATH
> Technical] FW: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt
>
> Hi Doron and Andrew,
>
>
>
> Thank you very much for
> the review and comments.
>
>
>
> 1. It is actually a
> working item in the draft per earlier comment. We agree with
> you that using the same key for MAC and encryption isn't a
> good practice. We thought of options that allow one to
> specify a separate MAC key by extending the current
> definition on the MAC algorithm type. Asking two keys isn't
> ideal for those pre-shared encryption key devices. In DSKPP,
> a MAC key was randomly generated and encrypted along with the
> secret. We have not had deep discussions on this. Thank you
> for raising the issue, and it will help us to make sure it is
> addressed in the final version.
>
>
>
> 2. The purpose of the
> ValueMAC is to serve integrity check of the data. It isn't
> intended for any sender authentication. On one hand, our
> initial version simply pass a hash value of the data to be
> encrypted, for example, ValueMAC = SHA_256(cleartext). Note
> that hashing over ciphertext doesn't serve the purpose. A
> man-in-the-middle may alter the ciphertext and generate hash
> accordingly. Therefore it is necessary to calculate it over
> the cleartext.
>
>
>
> When HMAC was chosen
> for the integrity check purpose, we still felt that the hash
> over the original data was good. The essential argument goes
> back to the first item: should the MAC key be a separate one.
> If it is a separate one, the security concern doesn't seem to exist.
>
>
>
> For simplicity, I
> consider that SHA_256(cleartext) is fine without requiring
> complexity in choosing MAC key for HMAC. Using the same key
> again isn't good. There are other ways to serve the integrity
> check, for example, encryption is over <cleartext> +
> <Encrypted(random data) with the cleartext>. The simpliest is
> <hash(cleartext)> with a strong hash function such as
> SHA_256. I don't think a strong hash and encrypted value
> together will reveal the cleartext.
>
>
>
> Suggestions are
> welcomed for making this choice.
>
>
>
> Thank you,
>
>
>
> - Ming
>
>
>
> ________________________________
>
> From: Doron Cohen
> [mailto:doronc at aladdin.com]
> Sent: Thursday, March
> 05, 2009 4:58 AM
> To:
> oath_technical at v2.listbox.com
> Cc: Andrew Lindell;
> oath_technical at v2.listbox.com
> Subject: RE: [OATH
> Technical] FW: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt
>
> Hi Philip,
>
>
>
> Below are a couple of
> comments I received from Aladdin's Chief Cryptographer,
> Yehuda (Andrew) Lindell . Yehuda will be glad to provide
> more clarifications if required.
>
>
>
> "When algorithms
> without integrity checks are used, such as AES-128-CBC, a
> keyed MAC value using the same key as the key encryption key
> MUST be placed in the <ValueMAC> element of the <Data>
> element. In this case the MAC algorithm type MUST be set in
> the <MACAlgorithm> element of the <KeyContainer> element.
> Implementations of PSKC MUST support HMAC-SHA1 (with the URI
> of http://www.w3.org/2000/09/xmldsig#hmac-sha1) as the
> mandatory-to-implement MAC algorithm.
>
>
>
> [Yehuda Lindell] This
> is very bad practice. You should not use the same key for
> different tasks. The solution to this (where an
> authenticated-encryption scheme is not used) is to use key
> derivation to obtain two keys from the single one, and then
> use the first for encryption and the second for the MAC.
>
>
>
> In section 4.2 the
> following appears:
>
>
>
> Additionally, a
> <ValueMac> element, which is populated with a MAC generated
> from the unencrypted value in case the encryption algorithm
> does not support integrity checks, MAY be included as a child
> element. The example shown at Figure 2 illustrates the usage
> of the <Data> element with two child elements, namely
> <Secret> and <Counter>. Both elements carry plaintext value
> within the <PlainValue> child element.
>
>
>
> [Yehuda Lindell] This
> says that the MAC is applied to the unencrypted value. This
> is bad practice (it is not always secure) and it's far better
> to generate the MAC by applying it to the encrypted
> ciphertext. In any case, this contradicts what appears below
> in Section 6.1 (Section 6.1 explicitly states that the MAC is
> applied to the encrypted value, which is the correct way to work).
>
>
>
>
>
> Best Regards
>
> Doron
>
>
>
> Doron Cohen
>
> CTO, Authentication
> Business Unit
>
> Aladdin Knowledge Systems
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> From: Philip Hoyer
> [mailto:philip.hoyer at actividentity.com]
> Sent: Tuesday, February
> 24, 2009 22:14
> To:
> oath_technical at v2.listbox.com
> Subject: [OATH
> Technical] FW: [KEYPROV] WGLC: draft-ietf-keyprov-pskc-02.txt
>
>
>
> Ladies and Gentlemen:
>
> Could I invite the
> participants on the list please to review the PSKC spec as
> below as the work started in OATH and it would be great to
> see what you think of it now.
>
>
>
> Philip
>
>
>
> ________________________________
>
> From:
> keyprov-bounces at ietf.org [mailto:keyprov-bounces at ietf.org] On
> Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
> Sent: Monday, February
> 23, 2009 12:14 PM
> To: KEYPROV
> Subject: [KEYPROV]
> WGLC: draft-ietf-keyprov-pskc-02.txt
>
>
>
> Hi all,
>
> this is a KEYPROV
> Working Group Last Call for comments on
>
> http://www.ietf.org/internet-drafts/draft-ietf-keyprov-pskc-02
> .txt
> <http://www.ietf.org/Web/internet-drafts/draft-ietf-keyprov-ps
> kc-02.txt>
>
> Please send your
> comments to the list by March 6, 2009.
>
> Ciao
> Hannes & Phillip
>
> ________________________________
>
> oath_technical | Archives
> <https://www.listbox.com/Web/member/archive/1323/=now>
> <https://www.listbox.com/Web/member/archive/rss/1323/> |
> Modify <https://www.listbox.com/Web/member/?&;> Your Subscription
>
> <http://www.listbox.com/Web/>
>
>
>
>
>
> **************************************************************
> ************************************
> The contents of this
> email and any attachments are confidential.
> It is intended for the
> named recipient(s) only.
> If you have received
> this email in error please notify the system manager or? the
> sender immediately and
> do not disclose the contents to anyone or make copies.
> ** eSafe scanned this
> email for viruses, vandals and malicious content **
>
> **************************************************************
> ************************************
>
> ________________________________
>
> oath_technical | Archives
> <https://www.listbox.com/Web/member/archive/1323/=now>
> <https://www.listbox.com/Web/member/archive/rss/1323/> |
> Modify
> <https://www.listbox.com/Web/member/?member_id=2265756&id_secr
> et=2265756-d89c009d> Your Subscription
>
> <http://www.listbox.com/Web/>
>
>
>
>
>
> **************************************************************
> ************************************
> The contents of this email and any
> attachments are confidential.
> It is intended for the named recipient(s) only.
> If you have received this email in
> error please notify the system manager or the
> sender immediately and do not disclose
> the contents to anyone or make copies.
> ** eSafe scanned this email for
> viruses, vandals and malicious content **
>
> **************************************************************
> ************************************
>
>
>
> **************************************************************
> ************************************
> The contents of this email and any attachments
> are confidential.
> It is intended for the named recipient(s) only.
> If you have received this email in error please
> notify the system manager or the
> sender immediately and do not disclose the
> contents to anyone or make copies.
> ** eSafe scanned this email for viruses,
> vandals and malicious content **
>
> **************************************************************
> ************************************
>
>
>
> **************************************************************
> ************************************
> The contents of this email and any attachments are confidential.
> It is intended for the named recipient(s) only.
> If you have received this email in error please notify
> the system manager or the
> sender immediately and do not disclose the contents to
> anyone or make copies.
> ** eSafe scanned this email for viruses, vandals and
> malicious content **
>
> **************************************************************
> ************************************
>
> **************************************************************
> ********************************
>
> The contents of this email and any attachments are confidential.
> It is intended for the named recipient(s) only.
> If you have received this email in error please notify the
> system manager or the sender immediately and do not disclose
> the contents to anyone or make copies.
> ** eSafe scanned this email for viruses, vandals and
> malicious content **
>
> **************************************************************
> ********************************
>
>