Very ugly SRK modulus extractor code created:
https://github.com/ThomasHabets/simple-tpm-pk11/blob/master/check-srk/check-srk.cc
Only works with WKS SRK PIN for now. Pull requests welcome.
Maybe someone could explain why GetPubKey for SRK gives me 28 bytes more
than I expected?
If those extra bytes are part of the modulus then my SRK is not vulnerable.
If they are not ("tail mod", in my code), then it is. (seems more likely)
So to correct my previous statement: it seems that the SRK *is* affected.
On 24 October 2017 at 10:55, Thomas Habets <[email protected]> wrote:
> At least my SRK doesn't appear to be vulnerable.
> I used marcan's much simplified test[1] on my extracted SRK, which says
> "vuln" for my key, but not for the SRK.
>
> I'll try to create some minimal stand alone code for checking this, unless
> someone beats me to it.
>
> [1] https://gist.github.com/marcan/fc87aa78085c2b6f979aefc73fdc381f
>
> On 23 October 2017 at 23:35, Bill Martin <[email protected]> wrote:
>
>> Questions for anyone :
>>
>> The storage root key is RSA-based, isn't it?
>>
>>
>> And one can get the public key by TSPI_TPM_OwnerGetSRKPubKey (in
>> TrouSerS). So this must mean based on the factorization flaw, the private
>> SRK component can be retrieved?
>>
>>
>> And same thing for the AIK, I suppose?
>>
>>
>> Concerns:
>>
>>
>> I don't have an application in use for AIK (other than I completed
>> RSA-DAA with commitments and full anonymity revocation). But I have an
>> application that depends on the integrity of TPM_NV_DefineSpace,
>> TPM_NV_Read and TPM_NV_Write. We might use TPM_Seal and TPM_Unseal. I
>> understand Infineon says the Endorsement key is not impacted by this.
>>
>>
>> thanks
>>
>>
>> Bill Martin
>>
>>
>> ------------------------------
>> *From:* Thomas Habets <[email protected]>
>> *Sent:* Sunday, October 22, 2017 3:13 AM
>> *To:* Dmitri Toubelis
>> *Cc:* Ken Goldman; trousers-users
>> *Subject:* Re: [TrouSerS-users] how to import RSA public key generated
>> using openssl into TPM..
>>
>> I think this unfortunately calls for an "I told you so" :-(
>>
>> https://threatpost.com/factorization-flaw-in-tpm-chips-
>> makes-attacks-on-rsa-private-keys-feasible/128474/
>>
>> "I think you either trust the TPM certification process or you don't"
>>
>> Auditability > trust.
>>
>>
>> On 3 January 2014 at 05:07, Dmitri Toubelis <[email protected]>
>> wrote:
>>
>>> > But in any case trust isn't an on-off thing in my opinion. I can
>>> > trust
>>> > the TPM chip to be a layer keeping my keys safer, without necessarily
>>> > having the same trust in its key generator. I remember seeing an
>>> > article recently that said for a certain class of US government
>>> > crypto
>>> > devices all keys are generated at the NSA, and are sent to these
>>> > devices.
>>>
>>> According to TCG specs a TPM chip supposed to implement True RNG, so
>>> there shouldn't be any PRNG/DRNG inside. If you are concerned about NSA
>>> back doors in some algorithms then TPM should be of least concern.
>>>
>>> I couldn't find any info on what types of True RNG are used inside TPM
>>> chips, but I remember reading about Infineon using dual-oscillator phase
>>> deviation method in their smart cards, so I would assume they would use the
>>> same technology in their TPMs. So, the only real concern for me would be
>>> quality of post processing of random data and here is a link to a research
>>> paper http://arxiv.org/ftp/arxiv/papers/1008/1008.2223.pdf that also
>>> analyzes entropy of RNGs. The bottom line is it is quite good.
>>>
>>> My take on this is that with the current state of technology one could
>>> think of using TPM's RNG for seeding entropy into the system rather then
>>> going the other way around (something like 'ekeyd' daemon for Linux but
>>> backed by TPM chip instead ;-).
>>>
>>> -Dmitri
>>>
>>>
>>
>>
>> --
>> typedef struct me_s {
>> char name[] = { "Thomas Habets" };
>> char email[] = { "[email protected] <[email protected]>" };
>> char kernel[] = { "Linux" };
>> char *pgpKey[] = { "http://www.habets.pp.se/pubkey.txt"; };
>> char pgp[] = { "9907 8698 8A24 F52F 1C2E 87F6 39A4 9EEA 460A 0169" };
>> char coolcmd[] = { "echo '. ./_&. ./_'>_;. ./_" };
>> } me_t;
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> TrouSerS-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/trousers-users
>>
>>
>
>
> --
> typedef struct me_s {
> char name[] = { "Thomas Habets" };
> char email[] = { "[email protected] <[email protected]>" };
> char kernel[] = { "Linux" };
> char *pgpKey[] = { "http://www.habets.pp.se/pubkey.txt"; };
> char pgp[] = { "9907 8698 8A24 F52F 1C2E 87F6 39A4 9EEA 460A 0169" };
> char coolcmd[] = { "echo '. ./_&. ./_'>_;. ./_" };
> } me_t;
>
--
typedef struct me_s {
char name[] = { "Thomas Habets" };
char email[] = { "[email protected] <[email protected]>" };
char kernel[] = { "Linux" };
char *pgpKey[] = { "http://www.habets.pp.se/pubkey.txt"; };
char pgp[] = { "9907 8698 8A24 F52F 1C2E 87F6 39A4 9EEA 460A 0169" };
char coolcmd[] = { "echo '. ./_&. ./_'>_;. ./_" };
} me_t;
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TrouSerS-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/trousers-users
