Menu
▾
▴
trustedjava-support — Trusted Java General Support
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
(4) |
Jul
(10) |
Aug
(6) |
Sep
(6) |
Oct
(5) |
Nov
(1) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
|
Feb
(14) |
Mar
(25) |
Apr
(9) |
May
(10) |
Jun
(9) |
Jul
(33) |
Aug
(52) |
Sep
(15) |
Oct
(6) |
Nov
(4) |
Dec
(6) |
| 2008 |
Jan
(27) |
Feb
(3) |
Mar
(6) |
Apr
(7) |
May
(8) |
Jun
(4) |
Jul
(21) |
Aug
(8) |
Sep
(9) |
Oct
(6) |
Nov
(1) |
Dec
(1) |
| 2009 |
Jan
(1) |
Feb
(1) |
Mar
(10) |
Apr
(7) |
May
(8) |
Jun
(10) |
Jul
(11) |
Aug
(17) |
Sep
(13) |
Oct
(13) |
Nov
(1) |
Dec
(5) |
| 2010 |
Jan
(5) |
Feb
(9) |
Mar
(12) |
Apr
(4) |
May
(5) |
Jun
(3) |
Jul
(7) |
Aug
(7) |
Sep
(3) |
Oct
(12) |
Nov
(5) |
Dec
(2) |
| 2011 |
Jan
(9) |
Feb
(3) |
Mar
(24) |
Apr
(3) |
May
(1) |
Jun
|
Jul
(3) |
Aug
(8) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
(4) |
Feb
|
Mar
|
Apr
(3) |
May
(12) |
Jun
(7) |
Jul
(9) |
Aug
|
Sep
(14) |
Oct
(19) |
Nov
(4) |
Dec
|
| 2013 |
Jan
(1) |
Feb
(3) |
Mar
(1) |
Apr
(5) |
May
(3) |
Jun
(7) |
Jul
(6) |
Aug
(4) |
Sep
(1) |
Oct
|
Nov
|
Dec
(2) |
| 2014 |
Jan
|
Feb
(2) |
Mar
(3) |
Apr
(1) |
May
(1) |
Jun
(6) |
Jul
(14) |
Aug
(5) |
Sep
(7) |
Oct
(3) |
Nov
|
Dec
(1) |
| 2015 |
Jan
(3) |
Feb
|
Mar
(4) |
Apr
|
May
(1) |
Jun
(9) |
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
(4) |
Dec
(4) |
| 2016 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
(2) |
Apr
(1) |
May
|
Jun
(1) |
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
(1) |
Nov
(1) |
Dec
(1) |
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
(11) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(2) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2024 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: toro83 <to...@gm...> - 2009-12-01 15:14:36
|
Hi, i'm using tpmemulator_0.6.1 and jTSS_0.4.1. Running our own written program and the test program distributed with jTSS under test folder i've encountered following problem, and i was unable to find a solution. Could somebody please help me? If some more information are needed, only ask :-) TSS Error: error layer: 0x3000 (TSP) error code (without layer): 0x04 error code (full): 0x3004 error message: An internal SW error has been detected. additional info: Unable to load 1.2 key in 1.1 TPM at iaik.tc.tss.impl.java.tsp.TcRsaKey.loadKey(TcRsaKey.java:647) .... Bye, Daniel |
|
From: Hardeep U. <har...@gm...> - 2009-11-29 22:15:50
|
Hi, I am trying to setup IAIK jTSS stack to use jTPMTools. I am new to all this and I am not sure how to configure jtss_tcs.ini and jtss_tsp.ini. I currently have TrustedGrub running on my Dell Latitude e5400 with a Broadcom TPM 1.2. I am using trousers and tpm-tools to do admin stuff for the tpm. I am trying to use jTPMTools to create aik and sign pcr values. What should the file path for persistent storage be when not using a database? Does it matter if I use text files or in-memory for the event manager? Do I need SOAP and what is it trying to do? Do I need to store trousers persistent storage to jTSS? Thanks --Hardeep |
|
From: Ronald T. <ron...@ia...> - 2009-10-29 12:38:58
|
Hi Arshad, Arshad Noor wrote: > I've noticed that when one application uses the TPM and is finished > with it (it has closed the context, but the application has not > exited yet), another application on the same machine cannot access > the TPM; The TPM is a system resource which requires a singleton management service. For instance to swap keys and auth sessions in and out. This can either be offered by the OS (i.e. Windows TBS) or by the TCS layer of the TSS. > Is this normal or a bug in JTSS? This is the normal behaviour in the TCG architecture. > If this is normal, how does one > enable multiple applications accessing a TPM on the same machine > (without the expense of SOAP calls)? You cannot. That's what SOAP is there for in the first place. Only exception is using Windows, but there your application (JVM) would need Administrator rights to access the TBS directly. Regards, Ronald -- Dipl.-Ing. Ronald Tögl phone +43 316/873-5502 Trusted Computing Labs fax +43 316/873-5520 IAIK ron...@ia... Graz University of Technology http://www.iaik.tugraz.at |
|
From: Arshad N. <ars...@st...> - 2009-10-28 17:24:57
|
Hi,
I've noticed that when one application uses the TPM and is finished
with it (it has closed the context, but the application has not
exited yet), another application on the same machine cannot access
the TPM; it throws the following error:
---------------
TSS Error:
error layer: 0x1000 (TDDL)
error code (without layer): 0x87
error code (full): 0x1087
error message: The request could not be performed because of an IO
device error.
additional info: Unable to open TPM device file /dev/tpm0.
Reason: /dev/tpm0 (Device or resource busy)
at
iaik.tc.tss.impl.java.tddl.TcTddlLinux.open(TcTddlLinux.java:107)
at iaik.tc.tss.impl.java.tddl.TcTddl.getInstance(TcTddl.java:44)
at
iaik.tc.tss.impl.java.tcs.TcTcsCommon.isOrdinalSupported(TcTcsCommon.java:66)
at iaik.tc.tss.impl.java.tcs.tcsi.TcTcsi.<clinit>(TcTcsi.java:112)
at
iaik.tc.tss.impl.java.tsp.tcsbinding.local.TcTcsBindingLocal.TcsiOpenContext(TcTcsBindingLocal.java:177)
at
iaik.tc.tss.impl.java.tsp.internal.TcTspInternal.TspContextOpen_Internal(TcTspInternal.java:378)
at iaik.tc.tss.impl.java.tsp.TcContext.connect(TcContext.java:167)
at iaik.tc.tss.impl.java.tsp.TcContext.connect(TcContext.java:199)
---------------
Is this normal or a bug in JTSS? If this is normal, how does one
enable multiple applications accessing a TPM on the same machine
(without the expense of SOAP calls)?
My environment is as follows:
CentOS: 2.6.18-164.el5 #1 SMP x86_64 x86_64 x86_64 GNU/Linux
JVM: Version "1.6.0_16"
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
JTSS: Version 0.4.1, using local bindings (not SOAP)
Thanks.
Arshad Noor
StrongAuth, Inc.
|
|
From: Ronald T. <ron...@ia...> - 2009-10-19 12:01:45
|
Hi, Could you please specify your system configuration? Is this the full error code? I think I have seen something similar on Windows 7 and with Atmel TPMs. Ronald Ronald Petrlic wrote: > Hi, > > when I try to read the SRK public key from my TPM via jtss I get the > error code "0x30c4" (The auth session has been closed by the TPM. The > provided auth session is not loaded in the TPM and is not cached. It > might have been evicted (from TPM and/or cache) due to space limitations.) > > Has someone else encountered this problem as well? > > All other TPM access works fine (e.g. reading PCRs, generating random > numbers,...) but when it comes to user authorization this problem > occurs. I am using the password that I have set when taking the > ownership with tpm.msc (Windows 7). > > Thanks a lot in advance and best regards, > Ronald > > -- Dipl.-Ing. Ronald Tögl phone +43 316/873-5502 Trusted Computing Labs fax +43 316/873-5520 IAIK ron...@ia... Graz University of Technology http://www.iaik.tugraz.at |
|
From: Ronald P. <rpe...@ma...> - 2009-10-19 11:48:13
|
Hi, when I try to read the SRK public key from my TPM via jtss I get the error code "0x30c4" (The auth session has been closed by the TPM. The provided auth session is not loaded in the TPM and is not cached. It might have been evicted (from TPM and/or cache) due to space limitations.) Has someone else encountered this problem as well? All other TPM access works fine (e.g. reading PCRs, generating random numbers,...) but when it comes to user authorization this problem occurs. I am using the password that I have set when taking the ownership with tpm.msc (Windows 7). Thanks a lot in advance and best regards, Ronald |
|
From: Ronald P. <rpe...@ca...> - 2009-10-09 08:32:44
|
Hi, Thank you for your reply. I've checked all my settings and access rights, looks good to me, however it won't work... I'm using local bindings. Best regards, Ronald ________________________________________ Von: Ronald Tögl [ron...@ia...] Gesendet: Montag, 5. Oktober 2009 10:33 An: tru...@li... Cc: Ronald Petrlic Betreff: [english 63%] Re: [Trustedjava-support] Communication with TPM fails Hi, This typically is a problem with the .ini file configurations and device access rights? Do you intend to use local or SOAP bindings? With local bindings you need to permit your application access to /dev/tpmX. With SOAP you need to install the system daemon - using the privileged tss user TrouSerS creates. I hope this helps a bit. Ronald Ronald Petrlic wrote: > Hi, > > When I try to run the simple test-script of jtss I get the error "The > communication with the TPM fails" (more precisely: "No TSP-TCS binding > could be initialized"). The config files "jtss_tcs.ini" and > "jTss_tsp.ini" have been properly adapted. I have also stopped > trousers (tcsd stop) - other software that uses the TPM (TrustedGRUB > and IMA work fine on my machine (Infineon TPM 1.2, Debian Linux with > kernel 2.6.30)). > > Thanks a lot in advance for any help, > Ronald > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > ------------------------------------------------------------------------ > > _______________________________________________ > Trustedjava-support mailing list > Tru...@li... > https://lists.sourceforge.net/lists/listinfo/trustedjava-support > -- Dipl.-Ing. Ronald Tögl phone +43 316/873-5502 Trusted Computing Labs fax +43 316/873-5520 IAIK ron...@ia... Graz University of Technology http://www.iaik.tugraz.at |
|
From: Ronald T. <ron...@ia...> - 2009-10-05 08:33:52
|
Hi, This typically is a problem with the .ini file configurations and device access rights? Do you intend to use local or SOAP bindings? With local bindings you need to permit your application access to /dev/tpmX. With SOAP you need to install the system daemon - using the privileged tss user TrouSerS creates. I hope this helps a bit. Ronald Ronald Petrlic wrote: > Hi, > > When I try to run the simple test-script of jtss I get the error "The > communication with the TPM fails" (more precisely: "No TSP-TCS binding > could be initialized"). The config files "jtss_tcs.ini" and > "jTss_tsp.ini" have been properly adapted. I have also stopped > trousers (tcsd stop) - other software that uses the TPM (TrustedGRUB > and IMA work fine on my machine (Infineon TPM 1.2, Debian Linux with > kernel 2.6.30)). > > Thanks a lot in advance for any help, > Ronald > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > ------------------------------------------------------------------------ > > _______________________________________________ > Trustedjava-support mailing list > Tru...@li... > https://lists.sourceforge.net/lists/listinfo/trustedjava-support > -- Dipl.-Ing. Ronald Tögl phone +43 316/873-5502 Trusted Computing Labs fax +43 316/873-5520 IAIK ron...@ia... Graz University of Technology http://www.iaik.tugraz.at |
|
From: Arshad N. <ars...@st...> - 2009-10-05 05:44:10
|
Hi Anders, Didn't realize you were on this forum; good to hear from you. There are business use-cases where key-migration is necessary; perhaps not so much in the authentication space as in the data encryption space. It is a critical requirement for some parts of our business. Arshad Noor StrongAuth, Inc. Anders Rundgren wrote: > I personally don't believe that Key Migration is a function that has any > legitimate use outside of a security-lab. > > Secure Credential Cloning is an established concept (already used by > millions of people in Sweden), that can be used to achieve a similar > effect but without the trauma associated with "opening" containers: > http://webpki.org/papers/keygen2/secure-key-store.pdf > (recently upgraded paper) > > Key import from a trusted service provider is another method that also > appears to be more useful than Key Migration. > > Anders |
|
From: Anders R. <and...@te...> - 2009-10-04 20:14:26
|
I personally don't believe that Key Migration is a function that has any legitimate use outside of a security-lab. Secure Credential Cloning is an established concept (already used by millions of people in Sweden), that can be used to achieve a similar effect but without the trauma associated with "opening" containers: http://webpki.org/papers/keygen2/secure-key-store.pdf (recently upgraded paper) Key import from a trusted service provider is another method that also appears to be more useful than Key Migration. Anders |
|
From: Arshad N. <ars...@st...> - 2009-10-04 19:46:48
|
I have solved the migration problem, Ronald, so please feel free
to ignore this last message of mine.
I will summarize the solution in a future e-mail to this list so
others might benefit from my experiments; the JTSS code is fine
and so are the STM and IFX TPM chips (I was able to migrate keys
from one to the other and in reverse too). The problem is that
neither the TCG documentation nor the JTSS APIs provide enough
clarity on how to accomplish key-migration.
I did discover in the process that the JTSS only works with the
MIGRATE option and not the REWRAP option; since one works for me,
I can live with this for now. The source code in JTSS tests and
the PDF link you sent in your last response were very helpful in
arriving at the migration solution.
Thank you.
Arshad Noor
StrongAuth, Inc.
Arshad Noor wrote:
> Ronald,
>
> I have confirmed that the Migration Ticket is not null; here are
> the contents of the migration ticket if it is of any help. The
> exception, unfortunately, continues to show up. Thanks.
>
> Arshad Noor
> StrongAuth, Inc.
>
> --------------
> migrationKey: algorithmParms:
> algorithmID: 1
> encScheme: 3
> sigScheme: 2
> parmSize: 12
> parms: 00 00 08 00 00 00 00 02 00 00 00 00
>
> pubKey:
> keyLength: 256
> key: 81 7d 3e 0a 64 8a 41 06 bf 1a 18 e2 5a b8 ec 6c
> d2 1d df b0 cb 8f 92 fe 0a ec 8d 87 07 b1 34 93
> aa 53 7d 96 be c2 05 e2 c7 6a 08 82 c5 2c 8b a3
> e9 e9 a2 96 a6 9f ef ba 5f 5a 0b aa 4a 07 10 93
> 62 ed b6 41 16 e9 4c 7b f3 69 de 09 58 0d cf 5f
> a7 25 30 62 26 0d 29 20 34 b1 69 84 dd c7 6f 08
> be 55 0a 0a da cb 55 4f 89 e9 e7 be 0b 40 1c 5a
> 71 f9 73 a0 1d 3c 02 84 66 19 80 d5 23 fb 19 5f
> 9e f0 9f e4 6c 48 9e 28 5c b7 aa f4 4d b1 9b 48
> 9d ce 89 a7 35 66 a0 33 86 68 c4 9b 7e d4 9c 1c
> e3 d4 8a 2d ac 4f 10 5e 73 e8 3b e0 c3 3c f3 42
> 01 ad da 2f 72 c6 30 c7 9a 55 99 9c c4 ab 6e 0c
> 75 22 7a 6f 65 b6 ef a6 89 ca 0c 59 70 f1 a6 21
> 04 51 c2 41 b3 52 28 ff 1b 3d 7a f2 15 31 9e e4
> 95 1b 63 1d 5e 73 67 af f3 54 3c 0e 77 6a 27 d7
> 7a c3 3c 79 d9 1d be e9 98 85 31 e3 ae 5c 90 e1
>
> migrationScheme: 2
> digest: digest: c1 0c 5e 5e d8 d4 b7 54 69 43 10 de 94 df 6f 6b
> b4 eb 0a 46
> --------------
>
> Arshad Noor wrote:
>> Thank you for the response and the document link, Ronald. The PDF
>> was so much clearer than the TCG specification, and the clouds parted
>> a little more. :-)
>>
>> While I progressed beyond the error I reported in this thread, I now
>> have a new error at createMigrationBlob() as follows:
>>
>> Exception in thread "main" java.lang.NullPointerException
>> at
>> iaik.tc.tss.impl.java.tsp.internal.TcTspInternal.TspCreateMigrationBlob_Internal(TcTspInternal.java:2134)
>> at
>> iaik.tc.tss.impl.java.tsp.TcRsaKey.createMigrationBlob(TcRsaKey.java:554)
>> at jtss.RewrapKey.main(RewrapKey.java:189)
>>
>> I do have a migration ticket that is created and authorized for the
>> destination TPM; what I don't know is if the internal structure of
>> the RsaKey of the destination TPM is OK; you will probably know more
>> from this exception message.
>>
>> Here are some snippets of the relevant code I'm using (I am trying
>> to move a Binding key from the Dell to the HP machine this time, so
>> the hprsakey is the destination PublicKey):
>>
>> ----------------------------
>> ...
>> // Create the destination key container
>> TcIRsaKey hprsakey = tpmctx.createRsaKeyObject(
>> TcTssConstants.TSS_KEY_TYPE_STORAGE |
>> TcTssConstants.TSS_KEY_SIZE_2048 |
>> TcTssConstants.TSS_KEY_VOLATILE |
>> TcTssConstants.TSS_KEY_AUTHORIZATION |
>> TcTssConstants.TSS_KEY_NOT_MIGRATABLE);
>> ...
>> ...
>> // Convert Java Public Key to TcIRsaKey
>> TcTpmPubkey hppubkey = TcCrypto.pubJavaToTpmKey(hppemkey);
>>
>> hprsakey.setAttribData(TcTssConstants.TSS_TSPATTRIB_KEY_BLOB,
>> TcTssConstants.TSS_TSPATTRIB_KEYBLOB_PUBLIC_KEY, hppubkey.getEncoded());
>>
>> hprsakey.setAttribUint32(TcTssConstants.TSS_TSPATTRIB_KEY_INFO,
>> TcTssConstants.TSS_TSPATTRIB_KEYINFO_ALGORITHM, TcTssConstants.TSS_ALG_RSA);
>>
>> hprsakey.setAttribUint32(TcTssConstants.TSS_TSPATTRIB_KEY_INFO,
>> TcTssConstants.TSS_TSPATTRIB_KEYINFO_ENCSCHEME,
>> TcTssConstants.TSS_ES_RSAESOAEP_SHA1_MGF1);
>>
>> hprsakey.setAttribUint32(TcTssConstants.TSS_TSPATTRIB_KEY_INFO,
>> TcTssConstants.TSS_TSPATTRIB_KEYINFO_SIGSCHEME,
>> TcTssConstants.TSS_SS_RSASSAPKCS1V15_SHA1);
>> System.out.println("HP SRK PublicKey parameters set..");
>>
>> ...
>> ...
>> TcTpmMigrationkeyAuth migticket = tpm.authorizeMigrationTicket(hprsakey,
>> TcTssConstants.TSS_MS_REWRAP);
>>
>> // Create the migration blob (throws exception)
>> TcBlobData migblob[] = srckey.createMigrationBlob(srk, migticket);
>> ----------------------------
>>
>> Any hint what might be throwing this new exception? Thank you for
>> your attention to this.
>>
>> Arshad Noor
>> StrongAuth, Inc.
>>
>> P.S. BTW, the JTSS API for TcITpm is a little different from the TCG
>> specification for the following method/function; the TCG documentation
>> states the function is TPM_AuthorizeMigrationKey (Section 11.3 Page 94)
>> while the TcITpm API has "authorizeMigrationTicket". Given that the
>> method is authorizing an RsaKey for use with a migration ticket, it
>> seems that the TCG name is a little clearer. Just an FYI. I am however,
>> very impressed with JTSS so far. :-)
>>
>> Ronald Tögl wrote:
>>
>>> Hello Arshad,
>>>
>>> I agree that the TCG specifications are not very helpful. The best intro
>>> on the topic I could find is
>>> http://www.ei.rub.de/media/ei/lehrmaterialien/trusted-computing/KeyReplication_.pdf
>>>
>>>
>>> As far as I remember we had some problems with TPM_MigrateKey last year,
>>> also concering different TPM implementations.
>>>
>>> For the dellrsakey object, make sure to use appropriate flags when first
>>> initializing the object with TcIContext.createRsaKeyObject(..). As you
>>> already have the RSA primes in place, you do not need to use
>>> createKey(). You should be able to do loadKey() instead.
>>>
>>> I hope this helps a little bit,
>>> Ronald
>>>
>>> Arshad Noor schrieb:
>>>> Hi,
>>>>
>>>> I'm having some trouble getting key-migration to work between
>>>> two machines with TPMs. My environment is as follows:
>>>>
>>>> Machine 1
>>>> ---------
>>>> TPM: STM v1.2
>>>> OS: CentOS 5.3 (64-bit)
>>>> JDK: 6 Update 16 (64-bit)
>>>> JTSS: 0.4.1
>>>>
>>>> Machine 2
>>>> ---------
>>>> TPM: Infineon v1.2
>>>> OS: CentOS 5.3 (64-bit)
>>>> JDK: 6 Update 16 (64-bit)
>>>> JTSS: 0.4.1
>>>>
>>>> First comment that worries me is that the JTSS test code has
>>>> explicitly commented out sections related to the Infineon TPM
>>>> as not working; can someone elaborate what might be causing
>>>> the migration to not work?
>>>>
>>>> I've plowed ahead and tried to see if I could get a Binding
>>>> key generated on Machine 2 migrated to Machine 1. To enable
>>>> this, I:
>>>>
>>>> 1) Exported the Public Key of a non-migratable Storage Key from
>>>> Machine 1 (the target destination for the migration) into a
>>>> PEM-encoded file;
>>>> 2) Transferred it to Machine 2 (the source for the migration);
>>>> 3) Created a TcTpmPubKey from the Java RSAPublicKey on Machine 2;
>>>> 4) Tried to create a TcIRsaKey from the TcTpmPubKey by setting
>>>> the following parameters (dellrsakey is the Public Key from
>>>> the destination machine - Machine 1):
>>>>
>>>> dellrsakey.setAttribData(TcTssConstants.TSS_TSPATTRIB_KEY_BLOB,
>>>> TcTssConstants.TSS_TSPATTRIB_KEYBLOB_PUBLIC_KEY,
>>>> dellpubkey.getEncoded());
>>>>
>>>> dellrsakey.setAttribUint32(TcTssConstants.TSS_TSPATTRIB_KEY_INFO,
>>>> TcTssConstants.TSS_TSPATTRIB_KEYINFO_ALGORITHM,
>>>> TcTssConstants.TSS_ALG_RSA);
>>>>
>>>> dellrsakey.setAttribUint32(TcTssConstants.TSS_TSPATTRIB_RSAKEY_INFO,
>>>> TcTssConstants.TSS_TSPATTRIB_KEYINFO_RSA_PRIMES, 2);
>>>>
>>>> dellrsakey.setAttribUint32(TcTssConstants.TSS_TSPATTRIB_KEY_INFO,
>>>> TcTssConstants.TSS_TSPATTRIB_KEYINFO_ENCSCHEME,
>>>> TcTssConstants.TSS_ES_RSAESOAEP_SHA1_MGF1);
>>>>
>>>> However, the migrateKey() method on Machine 2 throws the following
>>>> exception:
>>>>
>>>> ----------------------
>>>> iaik.tc.tss.api.exceptions.tsp.TcTspException:
>>>> TSS Error:
>>>> error layer: 0x3000 (TSP)
>>>> error code (without layer): 0x010e
>>>> error code (full): 0x310e
>>>> error message: The addressed key is currently not loaded.
>>>> additional info: publicKey is not loaded or key handle is invalid.
>>>>
>>>> at
>>>> iaik.tc.tss.impl.java.tsp.TcWorkingObject.checkKeyHandleNotNull(TcWorkingObject.java:113)
>>>>
>>>> at
>>>> iaik.tc.tss.impl.java.tsp.TcRsaKey.migrateKey(TcRsaKey.java:357)
>>>> at jtss.MigrateKey2.main(MigrateKey2.java:200)
>>>> ----------------------
>>>>
>>>> I presume this has to do with internal handles setup by the Impl
>>>> of the Context when createKey() is called by an RsaKey object.
>>>>
>>>> Upon trying to use createKey() an TcIRsaKey using the TcIRsaKey
>>>> object, even after setting up the above-mentioned attributes, I get
>>>> the following exception:
>>>>
>>>> ----------------------
>>>> iaik.tc.tss.api.exceptions.tcs.TcTpmException:
>>>>
>>>> TSS Error:
>>>> error layer: 0x00 (TPM)
>>>> error code (without layer): 0x28
>>>> error code (full): 0x28
>>>> error message: The key properties in TPM_KEY_PARMs are not supported
>>>> by this TPM
>>>>
>>>> at
>>>> iaik.tc.tss.impl.java.tcs.pbg.TcTpmCmdCommon.handleRetCode(TcTpmCmdCommon.java:73)
>>>>
>>>> at
>>>> iaik.tc.tss.impl.java.tcs.pbg.TcTpmCmdStorage.TpmCreateWrapKey(TcTpmCmdStorage.java:316)
>>>>
>>>> at
>>>> iaik.tc.tss.impl.java.tcs.tcsi.TcTcsi.TcsipCreateWrapKey(TcTcsi.java:754)
>>>> at
>>>> iaik.tc.tss.impl.java.tsp.tcsbinding.local.TcTcsBindingLocal.TcsipCreateWrapKey(TcTcsBindingLocal.java:450)
>>>>
>>>> at
>>>> iaik.tc.tss.impl.java.tsp.internal.TcTspInternal.TspCreateWrapKey_Internal(TcTspInternal.java:1842)
>>>>
>>>> at
>>>> iaik.tc.tss.impl.java.tsp.TcRsaKey.createKey(TcRsaKey.java:525)
>>>> at jtss.MigrateKey2.main(MigrateKey2.java:187)
>>>> ----------------------
>>>>
>>>> So, how does one create a TcIRsaKey from a public key of another TPM
>>>> to perform the key-migration? JTSS does not seem to offer an API to
>>>> make this possible and the only example in your test code (where a
>>>> TcIRsaKey is generated for a public key) is commented out because it
>>>> doesn't work on an Infineon or Atmel.
>>>>
>>>> So, how does one migrate a migratable key from one TPM to another in
>>>> the simplest possible manner using JTSS? A high-level explanation of
>>>> the steps would be extremely helpful; the TCG documents are not very
>>>> helpful or clear in this matter. Thanks.
>>>>
>>>> Arshad Noor
>>>> StrongAuth, Inc.
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>> Come build with us! The BlackBerry® Developer Conference in SF, CA
>>>> is the only developer event you need to attend this year. Jumpstart your
>>>> developing skills, take BlackBerry mobile applications to market and
>>>> stay ahead of the curve. Join us from November 9-12, 2009.
>>>> Register now!
>>>> http://p.sf.net/sfu/devconf
>>>> _______________________________________________
>>>> Trustedjava-support mailing list
>>>> Tru...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/trustedjava-support
>>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> ------------------------------------------------------------------------------
>>> Come build with us! The BlackBerry® Developer Conference in SF, CA
>>> is the only developer event you need to attend this year. Jumpstart your
>>> developing skills, take BlackBerry mobile applications to market and stay
>>> ahead of the curve. Join us from November 9-12, 2009. Register now!
>>> http://p.sf.net/sfu/devconf
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Trustedjava-support mailing list
>>> Tru...@li...
>>> https://lists.sourceforge.net/lists/listinfo/trustedjava-support
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry® Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9-12, 2009. Register now!
>> http://p.sf.net/sfu/devconf
>> _______________________________________________
>> Trustedjava-support mailing list
>> Tru...@li...
>> https://lists.sourceforge.net/lists/listinfo/trustedjava-support
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Trustedjava-support mailing list
> Tru...@li...
> https://lists.sourceforge.net/lists/listinfo/trustedjava-support
|
|
From: Arshad N. <ars...@st...> - 2009-10-02 18:10:15
|
Ronald,
I have confirmed that the Migration Ticket is not null; here are
the contents of the migration ticket if it is of any help. The
exception, unfortunately, continues to show up. Thanks.
Arshad Noor
StrongAuth, Inc.
--------------
migrationKey: algorithmParms:
algorithmID: 1
encScheme: 3
sigScheme: 2
parmSize: 12
parms: 00 00 08 00 00 00 00 02 00 00 00 00
pubKey:
keyLength: 256
key: 81 7d 3e 0a 64 8a 41 06 bf 1a 18 e2 5a b8 ec 6c
d2 1d df b0 cb 8f 92 fe 0a ec 8d 87 07 b1 34 93
aa 53 7d 96 be c2 05 e2 c7 6a 08 82 c5 2c 8b a3
e9 e9 a2 96 a6 9f ef ba 5f 5a 0b aa 4a 07 10 93
62 ed b6 41 16 e9 4c 7b f3 69 de 09 58 0d cf 5f
a7 25 30 62 26 0d 29 20 34 b1 69 84 dd c7 6f 08
be 55 0a 0a da cb 55 4f 89 e9 e7 be 0b 40 1c 5a
71 f9 73 a0 1d 3c 02 84 66 19 80 d5 23 fb 19 5f
9e f0 9f e4 6c 48 9e 28 5c b7 aa f4 4d b1 9b 48
9d ce 89 a7 35 66 a0 33 86 68 c4 9b 7e d4 9c 1c
e3 d4 8a 2d ac 4f 10 5e 73 e8 3b e0 c3 3c f3 42
01 ad da 2f 72 c6 30 c7 9a 55 99 9c c4 ab 6e 0c
75 22 7a 6f 65 b6 ef a6 89 ca 0c 59 70 f1 a6 21
04 51 c2 41 b3 52 28 ff 1b 3d 7a f2 15 31 9e e4
95 1b 63 1d 5e 73 67 af f3 54 3c 0e 77 6a 27 d7
7a c3 3c 79 d9 1d be e9 98 85 31 e3 ae 5c 90 e1
migrationScheme: 2
digest: digest: c1 0c 5e 5e d8 d4 b7 54 69 43 10 de 94 df 6f 6b
b4 eb 0a 46
--------------
Arshad Noor wrote:
> Thank you for the response and the document link, Ronald. The PDF
> was so much clearer than the TCG specification, and the clouds parted
> a little more. :-)
>
> While I progressed beyond the error I reported in this thread, I now
> have a new error at createMigrationBlob() as follows:
>
> Exception in thread "main" java.lang.NullPointerException
> at
> iaik.tc.tss.impl.java.tsp.internal.TcTspInternal.TspCreateMigrationBlob_Internal(TcTspInternal.java:2134)
> at
> iaik.tc.tss.impl.java.tsp.TcRsaKey.createMigrationBlob(TcRsaKey.java:554)
> at jtss.RewrapKey.main(RewrapKey.java:189)
>
> I do have a migration ticket that is created and authorized for the
> destination TPM; what I don't know is if the internal structure of
> the RsaKey of the destination TPM is OK; you will probably know more
> from this exception message.
>
> Here are some snippets of the relevant code I'm using (I am trying
> to move a Binding key from the Dell to the HP machine this time, so
> the hprsakey is the destination PublicKey):
>
> ----------------------------
> ...
> // Create the destination key container
> TcIRsaKey hprsakey = tpmctx.createRsaKeyObject(
> TcTssConstants.TSS_KEY_TYPE_STORAGE |
> TcTssConstants.TSS_KEY_SIZE_2048 |
> TcTssConstants.TSS_KEY_VOLATILE |
> TcTssConstants.TSS_KEY_AUTHORIZATION |
> TcTssConstants.TSS_KEY_NOT_MIGRATABLE);
> ...
> ...
> // Convert Java Public Key to TcIRsaKey
> TcTpmPubkey hppubkey = TcCrypto.pubJavaToTpmKey(hppemkey);
>
> hprsakey.setAttribData(TcTssConstants.TSS_TSPATTRIB_KEY_BLOB,
> TcTssConstants.TSS_TSPATTRIB_KEYBLOB_PUBLIC_KEY, hppubkey.getEncoded());
>
> hprsakey.setAttribUint32(TcTssConstants.TSS_TSPATTRIB_KEY_INFO,
> TcTssConstants.TSS_TSPATTRIB_KEYINFO_ALGORITHM, TcTssConstants.TSS_ALG_RSA);
>
> hprsakey.setAttribUint32(TcTssConstants.TSS_TSPATTRIB_KEY_INFO,
> TcTssConstants.TSS_TSPATTRIB_KEYINFO_ENCSCHEME,
> TcTssConstants.TSS_ES_RSAESOAEP_SHA1_MGF1);
>
> hprsakey.setAttribUint32(TcTssConstants.TSS_TSPATTRIB_KEY_INFO,
> TcTssConstants.TSS_TSPATTRIB_KEYINFO_SIGSCHEME,
> TcTssConstants.TSS_SS_RSASSAPKCS1V15_SHA1);
> System.out.println("HP SRK PublicKey parameters set..");
>
> ...
> ...
> TcTpmMigrationkeyAuth migticket = tpm.authorizeMigrationTicket(hprsakey,
> TcTssConstants.TSS_MS_REWRAP);
>
> // Create the migration blob (throws exception)
> TcBlobData migblob[] = srckey.createMigrationBlob(srk, migticket);
> ----------------------------
>
> Any hint what might be throwing this new exception? Thank you for
> your attention to this.
>
> Arshad Noor
> StrongAuth, Inc.
>
> P.S. BTW, the JTSS API for TcITpm is a little different from the TCG
> specification for the following method/function; the TCG documentation
> states the function is TPM_AuthorizeMigrationKey (Section 11.3 Page 94)
> while the TcITpm API has "authorizeMigrationTicket". Given that the
> method is authorizing an RsaKey for use with a migration ticket, it
> seems that the TCG name is a little clearer. Just an FYI. I am however,
> very impressed with JTSS so far. :-)
>
> Ronald Tögl wrote:
>
>> Hello Arshad,
>>
>> I agree that the TCG specifications are not very helpful. The best intro
>> on the topic I could find is
>> http://www.ei.rub.de/media/ei/lehrmaterialien/trusted-computing/KeyReplication_.pdf
>>
>>
>> As far as I remember we had some problems with TPM_MigrateKey last year,
>> also concering different TPM implementations.
>>
>> For the dellrsakey object, make sure to use appropriate flags when first
>> initializing the object with TcIContext.createRsaKeyObject(..). As you
>> already have the RSA primes in place, you do not need to use
>> createKey(). You should be able to do loadKey() instead.
>>
>> I hope this helps a little bit,
>> Ronald
>>
>> Arshad Noor schrieb:
>>> Hi,
>>>
>>> I'm having some trouble getting key-migration to work between
>>> two machines with TPMs. My environment is as follows:
>>>
>>> Machine 1
>>> ---------
>>> TPM: STM v1.2
>>> OS: CentOS 5.3 (64-bit)
>>> JDK: 6 Update 16 (64-bit)
>>> JTSS: 0.4.1
>>>
>>> Machine 2
>>> ---------
>>> TPM: Infineon v1.2
>>> OS: CentOS 5.3 (64-bit)
>>> JDK: 6 Update 16 (64-bit)
>>> JTSS: 0.4.1
>>>
>>> First comment that worries me is that the JTSS test code has
>>> explicitly commented out sections related to the Infineon TPM
>>> as not working; can someone elaborate what might be causing
>>> the migration to not work?
>>>
>>> I've plowed ahead and tried to see if I could get a Binding
>>> key generated on Machine 2 migrated to Machine 1. To enable
>>> this, I:
>>>
>>> 1) Exported the Public Key of a non-migratable Storage Key from
>>> Machine 1 (the target destination for the migration) into a
>>> PEM-encoded file;
>>> 2) Transferred it to Machine 2 (the source for the migration);
>>> 3) Created a TcTpmPubKey from the Java RSAPublicKey on Machine 2;
>>> 4) Tried to create a TcIRsaKey from the TcTpmPubKey by setting
>>> the following parameters (dellrsakey is the Public Key from
>>> the destination machine - Machine 1):
>>>
>>> dellrsakey.setAttribData(TcTssConstants.TSS_TSPATTRIB_KEY_BLOB,
>>> TcTssConstants.TSS_TSPATTRIB_KEYBLOB_PUBLIC_KEY,
>>> dellpubkey.getEncoded());
>>>
>>> dellrsakey.setAttribUint32(TcTssConstants.TSS_TSPATTRIB_KEY_INFO,
>>> TcTssConstants.TSS_TSPATTRIB_KEYINFO_ALGORITHM,
>>> TcTssConstants.TSS_ALG_RSA);
>>>
>>> dellrsakey.setAttribUint32(TcTssConstants.TSS_TSPATTRIB_RSAKEY_INFO,
>>> TcTssConstants.TSS_TSPATTRIB_KEYINFO_RSA_PRIMES, 2);
>>>
>>> dellrsakey.setAttribUint32(TcTssConstants.TSS_TSPATTRIB_KEY_INFO,
>>> TcTssConstants.TSS_TSPATTRIB_KEYINFO_ENCSCHEME,
>>> TcTssConstants.TSS_ES_RSAESOAEP_SHA1_MGF1);
>>>
>>> However, the migrateKey() method on Machine 2 throws the following
>>> exception:
>>>
>>> ----------------------
>>> iaik.tc.tss.api.exceptions.tsp.TcTspException:
>>> TSS Error:
>>> error layer: 0x3000 (TSP)
>>> error code (without layer): 0x010e
>>> error code (full): 0x310e
>>> error message: The addressed key is currently not loaded.
>>> additional info: publicKey is not loaded or key handle is invalid.
>>>
>>> at
>>> iaik.tc.tss.impl.java.tsp.TcWorkingObject.checkKeyHandleNotNull(TcWorkingObject.java:113)
>>>
>>> at
>>> iaik.tc.tss.impl.java.tsp.TcRsaKey.migrateKey(TcRsaKey.java:357)
>>> at jtss.MigrateKey2.main(MigrateKey2.java:200)
>>> ----------------------
>>>
>>> I presume this has to do with internal handles setup by the Impl
>>> of the Context when createKey() is called by an RsaKey object.
>>>
>>> Upon trying to use createKey() an TcIRsaKey using the TcIRsaKey
>>> object, even after setting up the above-mentioned attributes, I get
>>> the following exception:
>>>
>>> ----------------------
>>> iaik.tc.tss.api.exceptions.tcs.TcTpmException:
>>>
>>> TSS Error:
>>> error layer: 0x00 (TPM)
>>> error code (without layer): 0x28
>>> error code (full): 0x28
>>> error message: The key properties in TPM_KEY_PARMs are not supported
>>> by this TPM
>>>
>>> at
>>> iaik.tc.tss.impl.java.tcs.pbg.TcTpmCmdCommon.handleRetCode(TcTpmCmdCommon.java:73)
>>>
>>> at
>>> iaik.tc.tss.impl.java.tcs.pbg.TcTpmCmdStorage.TpmCreateWrapKey(TcTpmCmdStorage.java:316)
>>>
>>> at
>>> iaik.tc.tss.impl.java.tcs.tcsi.TcTcsi.TcsipCreateWrapKey(TcTcsi.java:754)
>>> at
>>> iaik.tc.tss.impl.java.tsp.tcsbinding.local.TcTcsBindingLocal.TcsipCreateWrapKey(TcTcsBindingLocal.java:450)
>>>
>>> at
>>> iaik.tc.tss.impl.java.tsp.internal.TcTspInternal.TspCreateWrapKey_Internal(TcTspInternal.java:1842)
>>>
>>> at
>>> iaik.tc.tss.impl.java.tsp.TcRsaKey.createKey(TcRsaKey.java:525)
>>> at jtss.MigrateKey2.main(MigrateKey2.java:187)
>>> ----------------------
>>>
>>> So, how does one create a TcIRsaKey from a public key of another TPM
>>> to perform the key-migration? JTSS does not seem to offer an API to
>>> make this possible and the only example in your test code (where a
>>> TcIRsaKey is generated for a public key) is commented out because it
>>> doesn't work on an Infineon or Atmel.
>>>
>>> So, how does one migrate a migratable key from one TPM to another in
>>> the simplest possible manner using JTSS? A high-level explanation of
>>> the steps would be extremely helpful; the TCG documents are not very
>>> helpful or clear in this matter. Thanks.
>>>
>>> Arshad Noor
>>> StrongAuth, Inc.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> Come build with us! The BlackBerry® Developer Conference in SF, CA
>>> is the only developer event you need to attend this year. Jumpstart your
>>> developing skills, take BlackBerry mobile applications to market and
>>> stay ahead of the curve. Join us from November 9-12, 2009.
>>> Register now!
>>> http://p.sf.net/sfu/devconf
>>> _______________________________________________
>>> Trustedjava-support mailing list
>>> Tru...@li...
>>> https://lists.sourceforge.net/lists/listinfo/trustedjava-support
>>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry® Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9-12, 2009. Register now!
>> http://p.sf.net/sfu/devconf
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Trustedjava-support mailing list
>> Tru...@li...
>> https://lists.sourceforge.net/lists/listinfo/trustedjava-support
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Trustedjava-support mailing list
> Tru...@li...
> https://lists.sourceforge.net/lists/listinfo/trustedjava-support
|
|
From: Ronald P. <ro...@pe...> - 2009-10-02 13:23:08
|
Hi, When I try to run the simple test-script of jtss I get the error "The communication with the TPM fails" (more precisely: "No TSP-TCS binding could be initialized"). The config files "jtss_tcs.ini" and "jTss_tsp.ini" have been properly adapted. I have also stopped trousers (tcsd stop) - other software that uses the TPM (TrustedGRUB and IMA work fine on my machine (Infineon TPM 1.2, Debian Linux with kernel 2.6.30)). Thanks a lot in advance for any help, Ronald |
|
From: Arshad N. <ars...@st...> - 2009-10-02 02:50:33
|
Thank you for the response and the document link, Ronald. The PDF
was so much clearer than the TCG specification, and the clouds parted
a little more. :-)
While I progressed beyond the error I reported in this thread, I now
have a new error at createMigrationBlob() as follows:
Exception in thread "main" java.lang.NullPointerException
at
iaik.tc.tss.impl.java.tsp.internal.TcTspInternal.TspCreateMigrationBlob_Internal(TcTspInternal.java:2134)
at
iaik.tc.tss.impl.java.tsp.TcRsaKey.createMigrationBlob(TcRsaKey.java:554)
at jtss.RewrapKey.main(RewrapKey.java:189)
I do have a migration ticket that is created and authorized for the
destination TPM; what I don't know is if the internal structure of
the RsaKey of the destination TPM is OK; you will probably know more
from this exception message.
Here are some snippets of the relevant code I'm using (I am trying
to move a Binding key from the Dell to the HP machine this time, so
the hprsakey is the destination PublicKey):
----------------------------
...
// Create the destination key container
TcIRsaKey hprsakey = tpmctx.createRsaKeyObject(
TcTssConstants.TSS_KEY_TYPE_STORAGE |
TcTssConstants.TSS_KEY_SIZE_2048 |
TcTssConstants.TSS_KEY_VOLATILE |
TcTssConstants.TSS_KEY_AUTHORIZATION |
TcTssConstants.TSS_KEY_NOT_MIGRATABLE);
...
...
// Convert Java Public Key to TcIRsaKey
TcTpmPubkey hppubkey = TcCrypto.pubJavaToTpmKey(hppemkey);
hprsakey.setAttribData(TcTssConstants.TSS_TSPATTRIB_KEY_BLOB,
TcTssConstants.TSS_TSPATTRIB_KEYBLOB_PUBLIC_KEY, hppubkey.getEncoded());
hprsakey.setAttribUint32(TcTssConstants.TSS_TSPATTRIB_KEY_INFO,
TcTssConstants.TSS_TSPATTRIB_KEYINFO_ALGORITHM, TcTssConstants.TSS_ALG_RSA);
hprsakey.setAttribUint32(TcTssConstants.TSS_TSPATTRIB_KEY_INFO,
TcTssConstants.TSS_TSPATTRIB_KEYINFO_ENCSCHEME,
TcTssConstants.TSS_ES_RSAESOAEP_SHA1_MGF1);
hprsakey.setAttribUint32(TcTssConstants.TSS_TSPATTRIB_KEY_INFO,
TcTssConstants.TSS_TSPATTRIB_KEYINFO_SIGSCHEME,
TcTssConstants.TSS_SS_RSASSAPKCS1V15_SHA1);
System.out.println("HP SRK PublicKey parameters set..");
...
...
TcTpmMigrationkeyAuth migticket = tpm.authorizeMigrationTicket(hprsakey,
TcTssConstants.TSS_MS_REWRAP);
// Create the migration blob (throws exception)
TcBlobData migblob[] = srckey.createMigrationBlob(srk, migticket);
----------------------------
Any hint what might be throwing this new exception? Thank you for
your attention to this.
Arshad Noor
StrongAuth, Inc.
P.S. BTW, the JTSS API for TcITpm is a little different from the TCG
specification for the following method/function; the TCG documentation
states the function is TPM_AuthorizeMigrationKey (Section 11.3 Page 94)
while the TcITpm API has "authorizeMigrationTicket". Given that the
method is authorizing an RsaKey for use with a migration ticket, it
seems that the TCG name is a little clearer. Just an FYI. I am however,
very impressed with JTSS so far. :-)
Ronald Tögl wrote:
>
> Hello Arshad,
>
> I agree that the TCG specifications are not very helpful. The best intro
> on the topic I could find is
> http://www.ei.rub.de/media/ei/lehrmaterialien/trusted-computing/KeyReplication_.pdf
>
>
> As far as I remember we had some problems with TPM_MigrateKey last year,
> also concering different TPM implementations.
>
> For the dellrsakey object, make sure to use appropriate flags when first
> initializing the object with TcIContext.createRsaKeyObject(..). As you
> already have the RSA primes in place, you do not need to use
> createKey(). You should be able to do loadKey() instead.
>
> I hope this helps a little bit,
> Ronald
>
> Arshad Noor schrieb:
>> Hi,
>>
>> I'm having some trouble getting key-migration to work between
>> two machines with TPMs. My environment is as follows:
>>
>> Machine 1
>> ---------
>> TPM: STM v1.2
>> OS: CentOS 5.3 (64-bit)
>> JDK: 6 Update 16 (64-bit)
>> JTSS: 0.4.1
>>
>> Machine 2
>> ---------
>> TPM: Infineon v1.2
>> OS: CentOS 5.3 (64-bit)
>> JDK: 6 Update 16 (64-bit)
>> JTSS: 0.4.1
>>
>> First comment that worries me is that the JTSS test code has
>> explicitly commented out sections related to the Infineon TPM
>> as not working; can someone elaborate what might be causing
>> the migration to not work?
>>
>> I've plowed ahead and tried to see if I could get a Binding
>> key generated on Machine 2 migrated to Machine 1. To enable
>> this, I:
>>
>> 1) Exported the Public Key of a non-migratable Storage Key from
>> Machine 1 (the target destination for the migration) into a
>> PEM-encoded file;
>> 2) Transferred it to Machine 2 (the source for the migration);
>> 3) Created a TcTpmPubKey from the Java RSAPublicKey on Machine 2;
>> 4) Tried to create a TcIRsaKey from the TcTpmPubKey by setting
>> the following parameters (dellrsakey is the Public Key from
>> the destination machine - Machine 1):
>>
>> dellrsakey.setAttribData(TcTssConstants.TSS_TSPATTRIB_KEY_BLOB,
>> TcTssConstants.TSS_TSPATTRIB_KEYBLOB_PUBLIC_KEY,
>> dellpubkey.getEncoded());
>>
>> dellrsakey.setAttribUint32(TcTssConstants.TSS_TSPATTRIB_KEY_INFO,
>> TcTssConstants.TSS_TSPATTRIB_KEYINFO_ALGORITHM,
>> TcTssConstants.TSS_ALG_RSA);
>>
>> dellrsakey.setAttribUint32(TcTssConstants.TSS_TSPATTRIB_RSAKEY_INFO,
>> TcTssConstants.TSS_TSPATTRIB_KEYINFO_RSA_PRIMES, 2);
>>
>> dellrsakey.setAttribUint32(TcTssConstants.TSS_TSPATTRIB_KEY_INFO,
>> TcTssConstants.TSS_TSPATTRIB_KEYINFO_ENCSCHEME,
>> TcTssConstants.TSS_ES_RSAESOAEP_SHA1_MGF1);
>>
>> However, the migrateKey() method on Machine 2 throws the following
>> exception:
>>
>> ----------------------
>> iaik.tc.tss.api.exceptions.tsp.TcTspException:
>> TSS Error:
>> error layer: 0x3000 (TSP)
>> error code (without layer): 0x010e
>> error code (full): 0x310e
>> error message: The addressed key is currently not loaded.
>> additional info: publicKey is not loaded or key handle is invalid.
>>
>> at
>> iaik.tc.tss.impl.java.tsp.TcWorkingObject.checkKeyHandleNotNull(TcWorkingObject.java:113)
>>
>> at
>> iaik.tc.tss.impl.java.tsp.TcRsaKey.migrateKey(TcRsaKey.java:357)
>> at jtss.MigrateKey2.main(MigrateKey2.java:200)
>> ----------------------
>>
>> I presume this has to do with internal handles setup by the Impl
>> of the Context when createKey() is called by an RsaKey object.
>>
>> Upon trying to use createKey() an TcIRsaKey using the TcIRsaKey
>> object, even after setting up the above-mentioned attributes, I get
>> the following exception:
>>
>> ----------------------
>> iaik.tc.tss.api.exceptions.tcs.TcTpmException:
>>
>> TSS Error:
>> error layer: 0x00 (TPM)
>> error code (without layer): 0x28
>> error code (full): 0x28
>> error message: The key properties in TPM_KEY_PARMs are not supported
>> by this TPM
>>
>> at
>> iaik.tc.tss.impl.java.tcs.pbg.TcTpmCmdCommon.handleRetCode(TcTpmCmdCommon.java:73)
>>
>> at
>> iaik.tc.tss.impl.java.tcs.pbg.TcTpmCmdStorage.TpmCreateWrapKey(TcTpmCmdStorage.java:316)
>>
>> at
>> iaik.tc.tss.impl.java.tcs.tcsi.TcTcsi.TcsipCreateWrapKey(TcTcsi.java:754)
>> at
>> iaik.tc.tss.impl.java.tsp.tcsbinding.local.TcTcsBindingLocal.TcsipCreateWrapKey(TcTcsBindingLocal.java:450)
>>
>> at
>> iaik.tc.tss.impl.java.tsp.internal.TcTspInternal.TspCreateWrapKey_Internal(TcTspInternal.java:1842)
>>
>> at
>> iaik.tc.tss.impl.java.tsp.TcRsaKey.createKey(TcRsaKey.java:525)
>> at jtss.MigrateKey2.main(MigrateKey2.java:187)
>> ----------------------
>>
>> So, how does one create a TcIRsaKey from a public key of another TPM
>> to perform the key-migration? JTSS does not seem to offer an API to
>> make this possible and the only example in your test code (where a
>> TcIRsaKey is generated for a public key) is commented out because it
>> doesn't work on an Infineon or Atmel.
>>
>> So, how does one migrate a migratable key from one TPM to another in
>> the simplest possible manner using JTSS? A high-level explanation of
>> the steps would be extremely helpful; the TCG documents are not very
>> helpful or clear in this matter. Thanks.
>>
>> Arshad Noor
>> StrongAuth, Inc.
>>
>>
>> ------------------------------------------------------------------------------
>>
>> Come build with us! The BlackBerry® Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and
>> stay ahead of the curve. Join us from November 9-12, 2009.
>> Register now!
>> http://p.sf.net/sfu/devconf
>> _______________________________________________
>> Trustedjava-support mailing list
>> Tru...@li...
>> https://lists.sourceforge.net/lists/listinfo/trustedjava-support
>>
>
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Trustedjava-support mailing list
> Tru...@li...
> https://lists.sourceforge.net/lists/listinfo/trustedjava-support
|
|
From: Ronald T. <ron...@ia...> - 2009-10-01 10:52:27
|
|
From: Arshad N. <ars...@st...> - 2009-09-28 00:35:06
|
Hi,
I'm having some trouble getting key-migration to work between
two machines with TPMs. My environment is as follows:
Machine 1
---------
TPM: STM v1.2
OS: CentOS 5.3 (64-bit)
JDK: 6 Update 16 (64-bit)
JTSS: 0.4.1
Machine 2
---------
TPM: Infineon v1.2
OS: CentOS 5.3 (64-bit)
JDK: 6 Update 16 (64-bit)
JTSS: 0.4.1
First comment that worries me is that the JTSS test code has
explicitly commented out sections related to the Infineon TPM
as not working; can someone elaborate what might be causing
the migration to not work?
I've plowed ahead and tried to see if I could get a Binding
key generated on Machine 2 migrated to Machine 1. To enable
this, I:
1) Exported the Public Key of a non-migratable Storage Key from
Machine 1 (the target destination for the migration) into a
PEM-encoded file;
2) Transferred it to Machine 2 (the source for the migration);
3) Created a TcTpmPubKey from the Java RSAPublicKey on Machine 2;
4) Tried to create a TcIRsaKey from the TcTpmPubKey by setting
the following parameters (dellrsakey is the Public Key from
the destination machine - Machine 1):
dellrsakey.setAttribData(TcTssConstants.TSS_TSPATTRIB_KEY_BLOB,
TcTssConstants.TSS_TSPATTRIB_KEYBLOB_PUBLIC_KEY, dellpubkey.getEncoded());
dellrsakey.setAttribUint32(TcTssConstants.TSS_TSPATTRIB_KEY_INFO,
TcTssConstants.TSS_TSPATTRIB_KEYINFO_ALGORITHM, TcTssConstants.TSS_ALG_RSA);
dellrsakey.setAttribUint32(TcTssConstants.TSS_TSPATTRIB_RSAKEY_INFO,
TcTssConstants.TSS_TSPATTRIB_KEYINFO_RSA_PRIMES, 2);
dellrsakey.setAttribUint32(TcTssConstants.TSS_TSPATTRIB_KEY_INFO,
TcTssConstants.TSS_TSPATTRIB_KEYINFO_ENCSCHEME,
TcTssConstants.TSS_ES_RSAESOAEP_SHA1_MGF1);
However, the migrateKey() method on Machine 2 throws the following
exception:
----------------------
iaik.tc.tss.api.exceptions.tsp.TcTspException:
TSS Error:
error layer: 0x3000 (TSP)
error code (without layer): 0x010e
error code (full): 0x310e
error message: The addressed key is currently not loaded.
additional info: publicKey is not loaded or key handle is invalid.
at
iaik.tc.tss.impl.java.tsp.TcWorkingObject.checkKeyHandleNotNull(TcWorkingObject.java:113)
at iaik.tc.tss.impl.java.tsp.TcRsaKey.migrateKey(TcRsaKey.java:357)
at jtss.MigrateKey2.main(MigrateKey2.java:200)
----------------------
I presume this has to do with internal handles setup by the Impl
of the Context when createKey() is called by an RsaKey object.
Upon trying to use createKey() an TcIRsaKey using the TcIRsaKey
object, even after setting up the above-mentioned attributes, I get
the following exception:
----------------------
iaik.tc.tss.api.exceptions.tcs.TcTpmException:
TSS Error:
error layer: 0x00 (TPM)
error code (without layer): 0x28
error code (full): 0x28
error message: The key properties in TPM_KEY_PARMs are not supported by
this TPM
at
iaik.tc.tss.impl.java.tcs.pbg.TcTpmCmdCommon.handleRetCode(TcTpmCmdCommon.java:73)
at
iaik.tc.tss.impl.java.tcs.pbg.TcTpmCmdStorage.TpmCreateWrapKey(TcTpmCmdStorage.java:316)
at
iaik.tc.tss.impl.java.tcs.tcsi.TcTcsi.TcsipCreateWrapKey(TcTcsi.java:754)
at
iaik.tc.tss.impl.java.tsp.tcsbinding.local.TcTcsBindingLocal.TcsipCreateWrapKey(TcTcsBindingLocal.java:450)
at
iaik.tc.tss.impl.java.tsp.internal.TcTspInternal.TspCreateWrapKey_Internal(TcTspInternal.java:1842)
at iaik.tc.tss.impl.java.tsp.TcRsaKey.createKey(TcRsaKey.java:525)
at jtss.MigrateKey2.main(MigrateKey2.java:187)
----------------------
So, how does one create a TcIRsaKey from a public key of another TPM
to perform the key-migration? JTSS does not seem to offer an API to
make this possible and the only example in your test code (where a
TcIRsaKey is generated for a public key) is commented out because it
doesn't work on an Infineon or Atmel.
So, how does one migrate a migratable key from one TPM to another in
the simplest possible manner using JTSS? A high-level explanation of
the steps would be extremely helpful; the TCG documents are not very
helpful or clear in this matter. Thanks.
Arshad Noor
StrongAuth, Inc.
|
|
From: Arshad N. <ars...@st...> - 2009-09-17 02:25:18
|
I've gotten past this issue, Ronald. When generating a non-migratable signing key-pair, I was NOT creating and assigning a Migration Policy to the key object since it is a non-migratable key. For some reason this caused the pop-up for the Owner's password to appear. When I create and assign a Migration Policy to the non-migratable signing key, the pop-up does not appear and the key is generated. I'm not sure if this is a bug in JTSS or some convoluted logic in the TCG specifications which I fail to understand (why assign a migration policy to a non-migratable key?). Thanks for your help, though. Arshad Noor StrongAuth, Inc. Arshad Noor wrote: > Thanks for the response, Ronald. > > I do have the key-hierarchy set reasonably correctly, I believe. > There is an SRK which is the root of the non-migratable signing > key as well as the migratable Binding Key. The only difference > is that I've set the SRK to have a real password as opposed to > the TSS_WELL_KNOWN_SECRET. > > The TPM Usage policy (with the owner's password) is assigned to > the TPM; the RK Usage policy (with its password) is assigned to > the SRK before the keys are generated. Each of the new keys has > their Usage policy and password assigned to their containers > before the createKey(srk, null) method is called. > > This works correctly without the pop-up for the Binding key but > not for the signing key. I can even generate a migratable > Storage key (with the SRK as its parent) without the pop-up. > That is what puzzles me. However, I will read the chapter again > in the book you suggested. Thanks. > > (As an aside, while I realize that each new key - Storage, Signing > and Binding - will have their Usage and Migration policies/passwords > typically established before the keys are generated, I fail to > understand why it is permissible for the SRK to have a "well known > secret". Any rationalization for this? Thanks). > > Arshad Noor > StrongAuth, Inc. > > > > Ronald Tögl wrote: >> Hi, >> >> First of all, there should not be a difference - I do not understand why >> it is there and will look into this. >> >> Second: Your key hierarchy is not correct. The TPM owner authorisation >> is only needed for a few restricted operations, not for everyday >> application key creation. >> >> A pop-up will always appear if a policy to some object is missing. The >> root for key creation should be the Storage Root Key, which needs to be >> designated as parent at key creation. Here you need to have the SRK >> object with the proper usage policy (by convention using >> TSS_WELL_KNOWN_SECRET) assigned. >> >> A good reading on how to handle TPM keys is >> "A Practical Guide to Trusted Computing" by David Challener; Kent Yoder; >> Ryan Catherman; David Safford; Leendert van Doorn >> >> hth, >> Ronald >> >> Arshad Noor wrote: >>> Hi, >>> >>> Is there a reason why the creation of a Signing key-pair always >>> prompts for the TPM Owner's password through a pop-up even though >>> the password is set in a BlobData structure and the Usage policy >>> for the TPM (set with the TPM Owner's password) is assigned to the >>> TPM? The signing keys are set to be non-migratable. >>> >>> This behavior is markedly different from creating migratable Binding >>> keys where the same secret and policy settings do not prompt for the >>> TPM Owner's password. >>> >>> Any pointers to an explanation, and a suggestion for how to avoid >>> the pop-up for the signing-key creation, would be appreciated. >>> Thanks. >>> >>> Arshad Noor >>> StrongAuth, Inc. >> > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Trustedjava-support mailing list > Tru...@li... > https://lists.sourceforge.net/lists/listinfo/trustedjava-support |
|
From: Arshad N. <ars...@st...> - 2009-09-16 15:04:38
|
Thanks for the response, Ronald. I do have the key-hierarchy set reasonably correctly, I believe. There is an SRK which is the root of the non-migratable signing key as well as the migratable Binding Key. The only difference is that I've set the SRK to have a real password as opposed to the TSS_WELL_KNOWN_SECRET. The TPM Usage policy (with the owner's password) is assigned to the TPM; the RK Usage policy (with its password) is assigned to the SRK before the keys are generated. Each of the new keys has their Usage policy and password assigned to their containers before the createKey(srk, null) method is called. This works correctly without the pop-up for the Binding key but not for the signing key. I can even generate a migratable Storage key (with the SRK as its parent) without the pop-up. That is what puzzles me. However, I will read the chapter again in the book you suggested. Thanks. (As an aside, while I realize that each new key - Storage, Signing and Binding - will have their Usage and Migration policies/passwords typically established before the keys are generated, I fail to understand why it is permissible for the SRK to have a "well known secret". Any rationalization for this? Thanks). Arshad Noor StrongAuth, Inc. Ronald Tögl wrote: > Hi, > > First of all, there should not be a difference - I do not understand why > it is there and will look into this. > > Second: Your key hierarchy is not correct. The TPM owner authorisation > is only needed for a few restricted operations, not for everyday > application key creation. > > A pop-up will always appear if a policy to some object is missing. The > root for key creation should be the Storage Root Key, which needs to be > designated as parent at key creation. Here you need to have the SRK > object with the proper usage policy (by convention using > TSS_WELL_KNOWN_SECRET) assigned. > > A good reading on how to handle TPM keys is > "A Practical Guide to Trusted Computing" by David Challener; Kent Yoder; > Ryan Catherman; David Safford; Leendert van Doorn > > hth, > Ronald > > Arshad Noor wrote: >> Hi, >> >> Is there a reason why the creation of a Signing key-pair always >> prompts for the TPM Owner's password through a pop-up even though >> the password is set in a BlobData structure and the Usage policy >> for the TPM (set with the TPM Owner's password) is assigned to the >> TPM? The signing keys are set to be non-migratable. >> >> This behavior is markedly different from creating migratable Binding >> keys where the same secret and policy settings do not prompt for the >> TPM Owner's password. >> >> Any pointers to an explanation, and a suggestion for how to avoid >> the pop-up for the signing-key creation, would be appreciated. >> Thanks. >> >> Arshad Noor >> StrongAuth, Inc. > > |
|
From: Ronald T. <ron...@ia...> - 2009-09-16 08:07:45
|
Hi, First of all, there should not be a difference - I do not understand why it is there and will look into this. Second: Your key hierarchy is not correct. The TPM owner authorisation is only needed for a few restricted operations, not for everyday application key creation. A pop-up will always appear if a policy to some object is missing. The root for key creation should be the Storage Root Key, which needs to be designated as parent at key creation. Here you need to have the SRK object with the proper usage policy (by convention using TSS_WELL_KNOWN_SECRET) assigned. A good reading on how to handle TPM keys is "A Practical Guide to Trusted Computing" by David Challener; Kent Yoder; Ryan Catherman; David Safford; Leendert van Doorn hth, Ronald Arshad Noor wrote: > Hi, > > Is there a reason why the creation of a Signing key-pair always > prompts for the TPM Owner's password through a pop-up even though > the password is set in a BlobData structure and the Usage policy > for the TPM (set with the TPM Owner's password) is assigned to the > TPM? The signing keys are set to be non-migratable. > > This behavior is markedly different from creating migratable Binding > keys where the same secret and policy settings do not prompt for the > TPM Owner's password. > > Any pointers to an explanation, and a suggestion for how to avoid > the pop-up for the signing-key creation, would be appreciated. > Thanks. > > Arshad Noor > StrongAuth, Inc. -- Dipl.-Ing. Ronald Tögl phone +43 316/873-5502 Trusted Computing Labs fax +43 316/873-5520 IAIK ron...@ia... Graz University of Technology http://www.iaik.tugraz.at |
|
From: Arshad N. <ars...@st...> - 2009-09-16 04:35:49
|
Hi, Is there a reason why the creation of a Signing key-pair always prompts for the TPM Owner's password through a pop-up even though the password is set in a BlobData structure and the Usage policy for the TPM (set with the TPM Owner's password) is assigned to the TPM? The signing keys are set to be non-migratable. This behavior is markedly different from creating migratable Binding keys where the same secret and policy settings do not prompt for the TPM Owner's password. Any pointers to an explanation, and a suggestion for how to avoid the pop-up for the signing-key creation, would be appreciated. Thanks. Arshad Noor StrongAuth, Inc. |
|
From: Arshad N. <ars...@st...> - 2009-09-10 01:58:52
|
Halleleujah! I figured it out.
I, obviously, misunderstood your response, Ronald (although I will
admit that your response was cryptic) :-)
Once I pored through various source files, I was finally able to
solve this. For those who are interested in the solution, here is
the snippet of code that worked:
---------------------
// Setup BoundData object
String plaintext = "To be....or not to be; that is the question!";
TcTpmBoundData boundata = new TcTpmBoundData();
boundata.setVer(TcTpmStructVer.TPM_V1_1);
boundata.setPayload(TcTpmConstants.TPM_PT_BIND);
boundata.setPayloadData(TcBlobData.newByteArray(plaintext.getBytes("UTF-16LE")));
System.out.println("Original plaintext data: " + plaintext);
// Encrypt with JCE Cipher and parameters
OAEPParameterSpec oaepspec = new OAEPParameterSpec("SHA1", "MGF1",
new MGF1ParameterSpec("SHA1"),
new PSource.PSpecified("TCPA".getBytes("ASCII")));
Cipher cipher = ipher.getInstance("RSA/ECB/OAEPWithSHA1AndMGF1Padding");
cipher.init(Cipher.ENCRYPT_MODE, rsabindkey, oaepspec);
byte[] ciphertext = cipher.doFinal(boundata.getEncoded().asByteArray());
System.out.println("Encrypted data: " +
new String(Base64.encode(ciphertext)));
// Setup EncData object for unbinding (decryption)
TcIEncData encdataobject =
tpmctx.createEncDataObject(TcTssConstants.TSS_ENCDATA_BIND);
encdataobject.setAttribData(TcTssConstants.TSS_TSPATTRIB_ENCDATA_BLOB,
TcTssConstants.TSS_TSPATTRIB_ENCDATABLOB_BLOB,
TcBlobData.newByteArray(ciphertext));
// Load bind key (with the SRK reference to decrypt bindkey)
bindkey.loadKey(srk);
// Decrypt the data
TcBlobData ptobject = encdataobject.unbind(bindkey);
// Display the decrypted plaintext
System.out.println("Decrypted data: " + ptobject.toString());
---------------------
Thanks for the pointer, Ronald. In the final analysis, it did
lead me to the answer.
This was fun! :-)
Arshad Noor
StrongAuth, Inc.
Arshad Noor wrote:
> Looking through the source of various objects, I added the
> following code to the test to explicitly set the values in
> the TcTpmBoundData object:
>
> -----------
> *TcTpmStructVer ver = new TcTpmStructVer();
> ver.setMajor((short) 1);
> ver.setMinor((short) 1);
> ver.setRevMajor((short) 0);
> ver.setRevMinor((short) 0);
> TcTpmBoundData boundata = new TcTpmBoundData();
> boundata.setVer(ver);
> boundata.setPayload(TcTpmConstants.TPM_PT_BIND);
> boundata.setPayloadData(TcBlobData.newByteArray(ciphertext));*
>
> TcIEncData encdataobject =
> tpmctx.createEncDataObject(TcTssConstants.TSS_ENCDATA_BIND);
> encdataobject.setAttribData(TcTssConstants.TSS_TSPATTRIB_ENCDATA_BLOB,
> TcTssConstants.TSS_TSPATTRIB_ENCDATABLOB_BLOB,
> *boundata.getEncoded()*);
> bindkey.loadKey(srk);
> TcBlobData ptobject = encdataobject.unbind(bindkey);
> -----------
>
> Unfortunately, the result is the same; same exception at the
> same location in the code. Hopefully, you'll provide some
> direction, Ronald. Thanks.
>
> Arshad Noor
> StrongAuth, Inc.
>
>
> Arshad Noor wrote:
>> Hi Ronald,
>>
>> Thanks for the pointer, but I'm afraid I'm missing the connection.
>>
>> I've reviewed the TCG Sec on tdTPM_BOUND_DATA and understand what
>> the 1-pager says; but what I'm missing is how does the TcIEncData's
>> unbind(TcIRsakey) method use it. Your examples in the JUnit source
>> do not use the TcTpmBoundData structure, so I'm missing the link.
>>
>> While I understand that the bind() operation in TcIEncData probably
>> creates the BoundData object internally and can therefore unbind it,
>> I'm not sure how to pass the TcTpmBoundData structure to the
>> TcIEncData object for the unbind() operation. Perhaps a few lines
>> of code will illuminate this better.
>>
>> Thanks.
>>
>> Arshad Noor
>> StrongAuth, Inc.
>>
>> Ronald Tögl wrote:
>>> Hi,
>>>
>>> The data you bind must be encrypted in a tdTPM_BOUND_DATA structure, the
>>> definition of which can be found in the TPM specifications.
>>>
>>> Ronald
>>>
>>> Arshad Noor wrote:
>>>> Hi,
>>>>
>>>> Recently started testing native JTSS 0.41. All tests pass on my
>>>> system (JDK6U15 64-bit on CentOS 5.3; TPM is an STM 1.2.4.30).
>>>>
>>>> When I try to encrypt data or a symmetric key (using SunJCE) with
>>>> an RSAPublicKey (whose Bind Key was generated in the TPM) and
>>>> decrypt the ciphertext with the Bind Key in the TPM, I run into
>>>> the following exception consistently:
>>>>
>>>> ---------------------
>>>> iaik.tc.tss.api.exceptions.tcs.TcTpmException:
>>>>
>>>> TSS Error:
>>>> error layer: 0x00 (TPM)
>>>> error code (without layer): 0x21
>>>> error code (full): 0x21
>>>> error message: The decryption process did not complete.
>>>>
>>>> at
>>>> iaik.tc.tss.impl.java.tcs.pbg.TcTpmCmdCommon.handleRetCode(TcTpmCmdCommon.java:73)
>>>>
>>>> at
>>>> iaik.tc.tss.impl.java.tcs.pbg.TcTpmCmdStorage.TpmUnBind(TcTpmCmdStorage.java:244)
>>>>
>>>> at
>>>> iaik.tc.tss.impl.java.tcs.tcsi.TcTcsi.TcsipUnBind(TcTcsi.java:1638)
>>>> at
>>>> iaik.tc.tss.impl.java.tsp.tcsbinding.local.TcTcsBindingLocal.TcsipUnBind(TcTcsBindingLocal.java:442)
>>>>
>>>> at
>>>> iaik.tc.tss.impl.java.tsp.internal.TcTspInternal.TspUnBind_Internal(TcTspInternal.java:1766)
>>>>
>>>> at
>>>> iaik.tc.tss.impl.java.tsp.TcEncData.unbind(TcEncData.java:221)
>>>> at
>>>> jtss.BindDataWithJCEUnbindWithTPM.main(BindDataWithJCEUnbindWithTPM.java:97)
>>>>
>>>> ---------------------
>>>>
>>>> I presume that it should be possible to do what I'm doing; I
>>>> didn't see anything that might otherwise indicate that it was
>>>> not possible. Here is the relevant section of the code that
>>>> I'm using; it is the unbind() method that causes the problem:
>>>>
>>>> ------------------------
>>>> String plaintext = "To be....or not to be; that is the question!";
>>>> Cipher cipher = Cipher.getInstance("RSA/ECB/PKCS1Padding");
>>>> cipher.init(Cipher.ENCRYPT_MODE, rsabindkey);
>>>> byte[] ciphertext = cipher.doFinal(plaintext.getBytes());
>>>> TcIEncData encdataobject =
>>>> tpmctx.createEncDataObject(TcTssConstants.TSS_ENCDATA_BIND);
>>>> encdataobject.setAttribData(TcTssConstants.TSS_TSPATTRIB_ENCDATA_BLOB,
>>>> TcTssConstants.TSS_TSPATTRIB_ENCDATABLOB_BLOB,
>>>> TcBlobData.newByteArray(ciphertext));
>>>> bindkey.loadKey(srk);
>>>> TcBlobData ptobject = encdataobject.unbind(bindkey);
>>>> ------------------------
>>>>
>>>> I get the same exception even if I use "NoPadding" in my
>>>> cipher's transform.
>>>>
>>>> Thanks for your help.
>>>>
>>>> Arshad Noor
>>>> StrongAuth, Inc.
>>>>
>>>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>> trial. Simplify your report design, integration and deployment - and focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Trustedjava-support mailing list
>> Tru...@li...
>> https://lists.sourceforge.net/lists/listinfo/trustedjava-support
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Trustedjava-support mailing list
> Tru...@li...
> https://lists.sourceforge.net/lists/listinfo/trustedjava-support
|
|
From: Arshad N. <ars...@st...> - 2009-09-10 00:50:41
|
Looking through the source of various objects, I added the
following code to the test to explicitly set the values in
the TcTpmBoundData object:
-----------
*TcTpmStructVer ver = new TcTpmStructVer();
ver.setMajor((short) 1);
ver.setMinor((short) 1);
ver.setRevMajor((short) 0);
ver.setRevMinor((short) 0);
TcTpmBoundData boundata = new TcTpmBoundData();
boundata.setVer(ver);
boundata.setPayload(TcTpmConstants.TPM_PT_BIND);
boundata.setPayloadData(TcBlobData.newByteArray(ciphertext));*
TcIEncData encdataobject =
tpmctx.createEncDataObject(TcTssConstants.TSS_ENCDATA_BIND);
encdataobject.setAttribData(TcTssConstants.TSS_TSPATTRIB_ENCDATA_BLOB,
TcTssConstants.TSS_TSPATTRIB_ENCDATABLOB_BLOB,
*boundata.getEncoded()*);
bindkey.loadKey(srk);
TcBlobData ptobject = encdataobject.unbind(bindkey);
-----------
Unfortunately, the result is the same; same exception at the
same location in the code. Hopefully, you'll provide some
direction, Ronald. Thanks.
Arshad Noor
StrongAuth, Inc.
Arshad Noor wrote:
> Hi Ronald,
>
> Thanks for the pointer, but I'm afraid I'm missing the connection.
>
> I've reviewed the TCG Sec on tdTPM_BOUND_DATA and understand what
> the 1-pager says; but what I'm missing is how does the TcIEncData's
> unbind(TcIRsakey) method use it. Your examples in the JUnit source
> do not use the TcTpmBoundData structure, so I'm missing the link.
>
> While I understand that the bind() operation in TcIEncData probably
> creates the BoundData object internally and can therefore unbind it,
> I'm not sure how to pass the TcTpmBoundData structure to the
> TcIEncData object for the unbind() operation. Perhaps a few lines
> of code will illuminate this better.
>
> Thanks.
>
> Arshad Noor
> StrongAuth, Inc.
>
> Ronald Tögl wrote:
>> Hi,
>>
>> The data you bind must be encrypted in a tdTPM_BOUND_DATA structure, the
>> definition of which can be found in the TPM specifications.
>>
>> Ronald
>>
>> Arshad Noor wrote:
>>> Hi,
>>>
>>> Recently started testing native JTSS 0.41. All tests pass on my
>>> system (JDK6U15 64-bit on CentOS 5.3; TPM is an STM 1.2.4.30).
>>>
>>> When I try to encrypt data or a symmetric key (using SunJCE) with
>>> an RSAPublicKey (whose Bind Key was generated in the TPM) and
>>> decrypt the ciphertext with the Bind Key in the TPM, I run into
>>> the following exception consistently:
>>>
>>> ---------------------
>>> iaik.tc.tss.api.exceptions.tcs.TcTpmException:
>>>
>>> TSS Error:
>>> error layer: 0x00 (TPM)
>>> error code (without layer): 0x21
>>> error code (full): 0x21
>>> error message: The decryption process did not complete.
>>>
>>> at
>>> iaik.tc.tss.impl.java.tcs.pbg.TcTpmCmdCommon.handleRetCode(TcTpmCmdCommon.java:73)
>>>
>>> at
>>> iaik.tc.tss.impl.java.tcs.pbg.TcTpmCmdStorage.TpmUnBind(TcTpmCmdStorage.java:244)
>>>
>>> at
>>> iaik.tc.tss.impl.java.tcs.tcsi.TcTcsi.TcsipUnBind(TcTcsi.java:1638)
>>> at
>>> iaik.tc.tss.impl.java.tsp.tcsbinding.local.TcTcsBindingLocal.TcsipUnBind(TcTcsBindingLocal.java:442)
>>>
>>> at
>>> iaik.tc.tss.impl.java.tsp.internal.TcTspInternal.TspUnBind_Internal(TcTspInternal.java:1766)
>>>
>>> at
>>> iaik.tc.tss.impl.java.tsp.TcEncData.unbind(TcEncData.java:221)
>>> at
>>> jtss.BindDataWithJCEUnbindWithTPM.main(BindDataWithJCEUnbindWithTPM.java:97)
>>>
>>> ---------------------
>>>
>>> I presume that it should be possible to do what I'm doing; I
>>> didn't see anything that might otherwise indicate that it was
>>> not possible. Here is the relevant section of the code that
>>> I'm using; it is the unbind() method that causes the problem:
>>>
>>> ------------------------
>>> String plaintext = "To be....or not to be; that is the question!";
>>> Cipher cipher = Cipher.getInstance("RSA/ECB/PKCS1Padding");
>>> cipher.init(Cipher.ENCRYPT_MODE, rsabindkey);
>>> byte[] ciphertext = cipher.doFinal(plaintext.getBytes());
>>> TcIEncData encdataobject =
>>> tpmctx.createEncDataObject(TcTssConstants.TSS_ENCDATA_BIND);
>>> encdataobject.setAttribData(TcTssConstants.TSS_TSPATTRIB_ENCDATA_BLOB,
>>> TcTssConstants.TSS_TSPATTRIB_ENCDATABLOB_BLOB,
>>> TcBlobData.newByteArray(ciphertext));
>>> bindkey.loadKey(srk);
>>> TcBlobData ptobject = encdataobject.unbind(bindkey);
>>> ------------------------
>>>
>>> I get the same exception even if I use "NoPadding" in my
>>> cipher's transform.
>>>
>>> Thanks for your help.
>>>
>>> Arshad Noor
>>> StrongAuth, Inc.
>>>
>>>
>>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Trustedjava-support mailing list
> Tru...@li...
> https://lists.sourceforge.net/lists/listinfo/trustedjava-support
|
|
From: Arshad N. <ars...@st...> - 2009-09-09 17:48:04
|
Hi Ronald,
Thanks for the pointer, but I'm afraid I'm missing the connection.
I've reviewed the TCG Sec on tdTPM_BOUND_DATA and understand what
the 1-pager says; but what I'm missing is how does the TcIEncData's
unbind(TcIRsakey) method use it. Your examples in the JUnit source
do not use the TcTpmBoundData structure, so I'm missing the link.
While I understand that the bind() operation in TcIEncData probably
creates the BoundData object internally and can therefore unbind it,
I'm not sure how to pass the TcTpmBoundData structure to the
TcIEncData object for the unbind() operation. Perhaps a few lines
of code will illuminate this better.
Thanks.
Arshad Noor
StrongAuth, Inc.
Ronald Tögl wrote:
> Hi,
>
> The data you bind must be encrypted in a tdTPM_BOUND_DATA structure, the
> definition of which can be found in the TPM specifications.
>
> Ronald
>
> Arshad Noor wrote:
>> Hi,
>>
>> Recently started testing native JTSS 0.41. All tests pass on my
>> system (JDK6U15 64-bit on CentOS 5.3; TPM is an STM 1.2.4.30).
>>
>> When I try to encrypt data or a symmetric key (using SunJCE) with
>> an RSAPublicKey (whose Bind Key was generated in the TPM) and
>> decrypt the ciphertext with the Bind Key in the TPM, I run into
>> the following exception consistently:
>>
>> ---------------------
>> iaik.tc.tss.api.exceptions.tcs.TcTpmException:
>>
>> TSS Error:
>> error layer: 0x00 (TPM)
>> error code (without layer): 0x21
>> error code (full): 0x21
>> error message: The decryption process did not complete.
>>
>> at
>> iaik.tc.tss.impl.java.tcs.pbg.TcTpmCmdCommon.handleRetCode(TcTpmCmdCommon.java:73)
>>
>> at
>> iaik.tc.tss.impl.java.tcs.pbg.TcTpmCmdStorage.TpmUnBind(TcTpmCmdStorage.java:244)
>>
>> at
>> iaik.tc.tss.impl.java.tcs.tcsi.TcTcsi.TcsipUnBind(TcTcsi.java:1638)
>> at
>> iaik.tc.tss.impl.java.tsp.tcsbinding.local.TcTcsBindingLocal.TcsipUnBind(TcTcsBindingLocal.java:442)
>>
>> at
>> iaik.tc.tss.impl.java.tsp.internal.TcTspInternal.TspUnBind_Internal(TcTspInternal.java:1766)
>>
>> at
>> iaik.tc.tss.impl.java.tsp.TcEncData.unbind(TcEncData.java:221)
>> at
>> jtss.BindDataWithJCEUnbindWithTPM.main(BindDataWithJCEUnbindWithTPM.java:97)
>>
>> ---------------------
>>
>> I presume that it should be possible to do what I'm doing; I
>> didn't see anything that might otherwise indicate that it was
>> not possible. Here is the relevant section of the code that
>> I'm using; it is the unbind() method that causes the problem:
>>
>> ------------------------
>> String plaintext = "To be....or not to be; that is the question!";
>> Cipher cipher = Cipher.getInstance("RSA/ECB/PKCS1Padding");
>> cipher.init(Cipher.ENCRYPT_MODE, rsabindkey);
>> byte[] ciphertext = cipher.doFinal(plaintext.getBytes());
>> TcIEncData encdataobject =
>> tpmctx.createEncDataObject(TcTssConstants.TSS_ENCDATA_BIND);
>> encdataobject.setAttribData(TcTssConstants.TSS_TSPATTRIB_ENCDATA_BLOB,
>> TcTssConstants.TSS_TSPATTRIB_ENCDATABLOB_BLOB,
>> TcBlobData.newByteArray(ciphertext));
>> bindkey.loadKey(srk);
>> TcBlobData ptobject = encdataobject.unbind(bindkey);
>> ------------------------
>>
>> I get the same exception even if I use "NoPadding" in my
>> cipher's transform.
>>
>> Thanks for your help.
>>
>> Arshad Noor
>> StrongAuth, Inc.
>>
>>
>
>
|
|
From: Arshad N. <ars...@st...> - 2009-09-09 17:43:29
|
Thanks for the pointer, Ronald; that was the answer. I can't
believe I forgot that fundamental mistake. :-)
Arshad Noor
StrongAuth, Inc.
Ronald Tögl wrote:
> Hi,
>
> While in general, for some complex cryptographic operations, the TCG
> specifications might require algorithms which are not supported by all
> of Sun's crypto providers, I do not think that this is the case here.
> jTSS uses "SHA-1" in exactly the same way as you do. I tend to believe
> that no incompatibilities between Sun and IAIK JCE implementations are
> likely at such a basic level.
>
> Rather check the string encodings of the text first. jTSS will, in
> accordance with the TSS specifications, use "UTF-16LE" by default.
> Please try text.getBytes(stringEncoding) and make sure that actually
> identical _byte_ arrays are hashed.
>
> Hoping to help,
> Ronald
>
>
> Arshad Noor wrote:
>> Hi,
>>
>> I'm having another problem related to SunJCE-JTSS interoperability;
>> I'm beginning to suspect I'm doing something wrong and hope someone
>> on the list can point me in the correct direction.
>>
>> I've generated a non-migratable signing key and used it to sign some
>> text. Upon using the JCE Signature object to verify the signature,
>> the verification always fails. Looking through the TestHash.java
>> source, I realized that it does not use the JCE for verification.
>>
>> I later ran a simple hash comparison and found that I'm getting
>> different values for the same text. That explains why the signature
>> never verifies with SunJCE; but why are the hashes different? Am I
>> missing something?
>>
>> Thanks for any pointers.
>>
>> Arshad Noor
>> StrongAuth, Inc.
>>
>> Same configuration as for the bind-unbind problem from this morning:
>>
>> JDK: 6 U15 - 64-bit
>> OS: CentOS 5.3 (Kernel 2.6.18-128.7.1.el5)
>> JTSS: 0.41
>> TPM: STM 1.2.4.30
>>
>> Sample test code:
>> ------------------
>> String text = "The quick brown fox jumps over the lazy dog.";
>> TcBlobData tbs = TcBlobData.newString(text);
>> TcIHash sha1hash =
>> tpmctx.createHashObject(TcTssConstants.TSS_HASH_SHA1);
>> sha1hash.updateHashValue(tbs);
>> System.out.println("Hash from TPM is: " + new
>> String(Base64.encode(sha1hash.getHashValue().asByteArray())));
>> MessageDigest md = MessageDigest.getInstance("SHA1");
>> System.out.println("Hash from JCE is: " + new
>> String(Base64.encode(md.digest(text.getBytes()))));
>> ------------------
>>
>
|
|
From: Ronald T. <ron...@ia...> - 2009-09-09 09:23:32
|
Hi,
While in general, for some complex cryptographic operations, the TCG
specifications might require algorithms which are not supported by all
of Sun's crypto providers, I do not think that this is the case here.
jTSS uses "SHA-1" in exactly the same way as you do. I tend to believe
that no incompatibilities between Sun and IAIK JCE implementations are
likely at such a basic level.
Rather check the string encodings of the text first. jTSS will, in
accordance with the TSS specifications, use "UTF-16LE" by default.
Please try text.getBytes(stringEncoding) and make sure that actually
identical _byte_ arrays are hashed.
Hoping to help,
Ronald
Arshad Noor wrote:
> Hi,
>
> I'm having another problem related to SunJCE-JTSS interoperability;
> I'm beginning to suspect I'm doing something wrong and hope someone
> on the list can point me in the correct direction.
>
> I've generated a non-migratable signing key and used it to sign some
> text. Upon using the JCE Signature object to verify the signature,
> the verification always fails. Looking through the TestHash.java
> source, I realized that it does not use the JCE for verification.
>
> I later ran a simple hash comparison and found that I'm getting
> different values for the same text. That explains why the signature
> never verifies with SunJCE; but why are the hashes different? Am I
> missing something?
>
> Thanks for any pointers.
>
> Arshad Noor
> StrongAuth, Inc.
>
> Same configuration as for the bind-unbind problem from this morning:
>
> JDK: 6 U15 - 64-bit
> OS: CentOS 5.3 (Kernel 2.6.18-128.7.1.el5)
> JTSS: 0.41
> TPM: STM 1.2.4.30
>
> Sample test code:
> ------------------
> String text = "The quick brown fox jumps over the lazy dog.";
> TcBlobData tbs = TcBlobData.newString(text);
> TcIHash sha1hash =
> tpmctx.createHashObject(TcTssConstants.TSS_HASH_SHA1);
> sha1hash.updateHashValue(tbs);
> System.out.println("Hash from TPM is: " + new
> String(Base64.encode(sha1hash.getHashValue().asByteArray())));
> MessageDigest md = MessageDigest.getInstance("SHA1");
> System.out.println("Hash from JCE is: " + new
> String(Base64.encode(md.digest(text.getBytes()))));
> ------------------
>
--
Dipl.-Ing. Ronald Tögl phone +43 316/873-5502
Trusted Computing Labs fax +43 316/873-5520
IAIK ron...@ia...
Graz University of Technology http://www.iaik.tugraz.at
|
87 messages has been excluded from this view by a project administrator.
