Menu
▾
▴
Re: [TrouSerS-users] Verify wrap public key is from TPM
|
From: dorner <do...@in...> - 2013-09-15 16:16:04
|
On 09/15/2013 04:50 PM, Ceri Coburn wrote: > > Essentially what I am looking to do is send encrypted information from > the server to the client. The server will have pre-existing knowledge > of the public key for the device which it will already trust, but I'm > just trying to ascertain which type of key to use. I'm ideally > looking for a key which is only tied to PCR values and not a password, > so likely to be a child key of the SRK. Is there still a requirement > to use the SRK password when using a child key with different access > rights to the SRK? > > If I can achieve the above, then the second phase will be to issue a > new key on the client device and send to the server when the client > software is updated, but this is where the server needs to make sure > the new updated key is indeed from the same TPM, which is where I > assume the TPM_CertifyKey and EK public key come into play. If I > cannot do this then my other option is not to tie the key to any of > the PCR's that are used for the client software and keep the keys > static throughout all versions, but then that leaves the client > software open to attack. > > Thanks. > > *From:*David Challener [mailto:dav...@gm...] > *Sent:* 15 September 2013 15:24 > *To:* Ceri Coburn > *Subject:* Re: [TrouSerS-users] Verify wrap public key is from TPM > > It isn't really claer what you want to do. You can create a signing > key in the server locked to the new pcrs and migrate it to the client, > or create it in the client and certify it ith the client's aik, or > anything you want. > > On Sep 15, 2013 6:56 AM, "Ceri Coburn" <cer...@gm... > <mailto:cer...@gm...>> wrote: > > Thanks for the response. > > In regards to Identity Management, the client devices are controlled > internally also, so before they are sent to their final destination we > are able to generate an AIK and store the public key/cert on the > server, basically allowing us to confirm an authenticated client > beforehand. > > The problem we have is software updates, since the key will be wrapped > with PCR values states, after a software update the PCR's would have > changed. So remotely the client will need to generate a new key > wrapped to new PCR values. Or do you think there is a better way to > do this without the need to generate a new key pair every time the > client software is updated? > > Thank > > *From:*dorner [mailto:do...@in...] > *Sent:* 14 September 2013 18:36 > *To:* tro...@li... > <mailto:tro...@li...> > *Subject:* Re: [TrouSerS-users] Verify wrap public key is from TPM > > On 09/13/2013 04:21 PM, cer...@gm... > <mailto:cer...@gm...> wrote: > > The public keys stored on the server are the public key components > from client device and were not generated by the server, there is > no TPM based hardware on the server side. Basically I'm > generating a new binding key on the client device and sending the > public portion back to the server so at a later date and encrypted > payload can be sent back to the client using that public key. But > before accepting the public key from the client the server should > verify that the public key it has received is indeed generated > from the TPM and not some rouge public key which an attacker has > the corresponding private key portion. > > *From:*David Challener [mailto:dav...@gm...] > *Sent:* 13 September 2013 15:14 > *To:* Ceri Coburn > *Subject:* Re: [TrouSerS-users] Verify wrap public key is from TPM > > I don't understand the question. > > If the public key represents a non-migratable key generated by the > server, and the clients have a public key corresponding to a > server AIK, then the server's AIK can certify the first public key. > > On Fri, Sep 13, 2013 at 10:08 AM, Ceri Coburn > <cer...@gm... <mailto:cer...@gm...>> wrote: > > Hi All, > > I have just started using trousers for an internal project of > mine. I have a client/server based system where on the server > there is a copy of all SRK and EK public keys from each client. > During some part of our client communication the public part of > newly generated wrap key where the SRK is the parent key is sent > to the server. Is there a way to verify that this public key was > indeed generated from the TPM at the server side? > > Thanks. > > > ------------------------------------------------------------------------------ > How ServiceNow helps IT people transform IT departments: > 1. Consolidate legacy IT systems to a single system of record for IT > 2. Standardize and globalize service processes across IT > 3. Implement zero-touch automation to replace manual, redundant tasks > http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk > _______________________________________________ > TrouSerS-users mailing list > Tro...@li... > <mailto:Tro...@li...> > https://lists.sourceforge.net/lists/listinfo/trousers-users > > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud > service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ > > ------------------------------------------------------------------------------ > > How ServiceNow helps IT people transform IT departments: > > 1. Consolidate legacy IT systems to a single system of record for IT > > 2. Standardize and globalize service processes across IT > > 3. Implement zero-touch automation to replace manual, redundant tasks > > http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk > > _______________________________________________ > > TrouSerS-users mailing list > > Tro...@li... <mailto:Tro...@li...> > > https://lists.sourceforge.net/lists/listinfo/trousers-users > > Hey Ceri, > > > *Short version*: > > AIK could be used to prove existence of binding key inside TPM, but > identity management required to ensure that binding key comes from the > right person. > > ---- > > I will try to explain as good as I can and I hope I ll get it right, > since its been a while since I last dealt with AIKs and their notion > of identity. I think there are two aspects that may be relevant to > you: the first is to prove that a key only exists inside a TPM, and > the second is the identity of the client, which submits the key. > > *Prove that a key is inside a TPM:* > > Afaik the only TPM-keys, which can be proven to exist only inside a > TPM are Attestation Identity Keys (AIKs). You can prove their origin > via an AIK certificate if all the required mechanisms are in place. To > work in an entirely secure way, that would require a > platform-certificate (for the EK), which is passed to a privacy CA > along with the EK-signed AIK pubkey, which generates an > AIK-certificate, if the attestation of the key to the CA is > successful. Afaik there is no publicly available infrastructure to do > this right now. I think Infineon is the only one who ships platform > certificates for some TPMs and the only publicly available PCA is > privacyca.com <http://privacyca.com>, which describes itself as > experimental tech demo. > > I think you can use an AIK as binding key (AIKs are nothing more than > RSA-keys with this attestation feature, so it should work, unless the > spec disallows it for some specific reason). In that case the client > could use his AIK-cert to prove that the key exists inside a > legitimate TPM. However, that would usually not ensure that the AIK > belongs to the user you think it comes from. > > *Identity management:* > > I think your concept has a more generic problem to it, which is not > that easy to fix, and is not a TPM-issue: What you are basically > asking for imo is a way for the server to identify the client without > previous knowledge of the client. Even if you knew the AIK came from a > TPM, it could still come from an attacker's TPM. So what you need is a > way to establish identities. Of course you could also accept anyone as > whoever he claims he is at first, but in that case anyone can claim to > be anyone and I think your system is meant to hand over some > information/data only to a very specific person. > > To sum this up: you need to decide on a way to determine identities, > if you have not done that. If you have identity-management in place, > signing the binding-pubkey with the identity-privkey should do the > job. If you want to make sure that the binding key belongs to a > person/entity, it has to prove his/her ID. That is why you have to > sign the public part of the binding-key. I think the TPM is not the > best choice to establish the ID of a person, so you may need a > different solution there - see smart cards e.g.. > > I hope I was of some help to you. > > Best regards, > > M. Dorner > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ > > > ------------------------------------------------------------------------------ > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, > SharePoint > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack > includes > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. > http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk > _______________________________________________ > TrouSerS-users mailing list > Tro...@li... > <mailto:Tro...@li...> > https://lists.sourceforge.net/lists/listinfo/trousers-users > > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ > > > > ------------------------------------------------------------------------------ > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. > http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk > > > _______________________________________________ > TrouSerS-users mailing list > Tro...@li... > https://lists.sourceforge.net/lists/listinfo/trousers-users Ceri, knowing the usage-scenario, I can be a bit more specific than before. I was suspecting something like this, but I was not sure, so I stayed as generic as possible. Being in an enterprise-scenario, where privacy doesn't matter should make a lot of things easier, especially since you can, as Chris already pointed out, run your own "Privacy"CA and rely on the EKs to identify Hosts. You can create AIKs from them and use these as ephemeral ID-keys. In any non-enterprise-scenario, that would be a privacy issue. *I think* *Chris already mentioned the right way to use the EKs/AIKs in that case*, so I will not address it any further. If you need to make sure data can only be used when some PCRs are in a certain state, you will have to use the *sealing operations* of the TPM. Since you will be the one generating the keys as well as using them, you should be able use a hardcoded WKS to avoid querying for a password. I am not sure what your idea of the SRK is, but I think all children of the SRK are storage keys, i.e. they encrypt other keys, but are not used for signing etc.. Thus your key will probably be encrypted by the SRK or one of its children, but will not be a child of it itself. If you want to get familiar with the API, you can search the list for advice on where to start, if you want to code using the trousers API and you will find some posts, but to make it short I think the book recommended by Chris and the testsuite <http://sourceforge.net/projects/trousers/files/TSS%20API%20test%20suite/> are the most important sources. I would suggest signing the ephemeral sealing key with an AIK, but I don't remember well enough if you can simply sign anything with an AIK, so I cannot really give a definite answer to the second part of your question. What you are thinking of sounds like you want to seal directly to an AIK, and I think that might cause you more trouble than necessary, because you would have to run the AIK-certification process every single time, when the only thing you need is a new sealing-key, not a new identity-key. Best regards, Michael |
