You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
|
Feb
|
Mar
(6) |
Apr
|
May
(32) |
Jun
(21) |
Jul
(27) |
Aug
(12) |
Sep
(34) |
Oct
(53) |
Nov
(36) |
Dec
(39) |
2006 |
Jan
(31) |
Feb
(24) |
Mar
(60) |
Apr
(20) |
May
(27) |
Jun
(82) |
Jul
(92) |
Aug
(70) |
Sep
(61) |
Oct
(94) |
Nov
(116) |
Dec
(50) |
2007 |
Jan
(145) |
Feb
(113) |
Mar
(87) |
Apr
(82) |
May
(46) |
Jun
(28) |
Jul
(56) |
Aug
(98) |
Sep
(51) |
Oct
(28) |
Nov
(65) |
Dec
(19) |
2008 |
Jan
(62) |
Feb
(65) |
Mar
(59) |
Apr
(30) |
May
(34) |
Jun
(19) |
Jul
(40) |
Aug
(28) |
Sep
(105) |
Oct
(21) |
Nov
(16) |
Dec
(6) |
2009 |
Jan
(24) |
Feb
(23) |
Mar
(29) |
Apr
(15) |
May
(9) |
Jun
(11) |
Jul
(34) |
Aug
(45) |
Sep
(18) |
Oct
(21) |
Nov
(26) |
Dec
(22) |
2010 |
Jan
(15) |
Feb
(12) |
Mar
(7) |
Apr
(9) |
May
(5) |
Jun
(20) |
Jul
(10) |
Aug
(34) |
Sep
(23) |
Oct
(14) |
Nov
(27) |
Dec
(2) |
2011 |
Jan
(5) |
Feb
|
Mar
(5) |
Apr
(1) |
May
(15) |
Jun
(1) |
Jul
(5) |
Aug
(33) |
Sep
(11) |
Oct
(12) |
Nov
(11) |
Dec
|
2012 |
Jan
(23) |
Feb
(12) |
Mar
|
Apr
(7) |
May
(5) |
Jun
(4) |
Jul
(5) |
Aug
(3) |
Sep
(21) |
Oct
(5) |
Nov
(10) |
Dec
(7) |
2013 |
Jan
(22) |
Feb
(9) |
Mar
(32) |
Apr
(2) |
May
(2) |
Jun
(4) |
Jul
(12) |
Aug
(21) |
Sep
(29) |
Oct
(12) |
Nov
(28) |
Dec
(10) |
2014 |
Jan
(23) |
Feb
(21) |
Mar
(30) |
Apr
(17) |
May
(25) |
Jun
(18) |
Jul
(4) |
Aug
(9) |
Sep
(8) |
Oct
(24) |
Nov
(43) |
Dec
(18) |
2015 |
Jan
(22) |
Feb
(6) |
Mar
(21) |
Apr
|
May
(2) |
Jun
(38) |
Jul
(4) |
Aug
(12) |
Sep
(18) |
Oct
(1) |
Nov
(5) |
Dec
(2) |
2016 |
Jan
(3) |
Feb
(10) |
Mar
(27) |
Apr
(8) |
May
(11) |
Jun
(22) |
Jul
(11) |
Aug
(13) |
Sep
(7) |
Oct
(1) |
Nov
(5) |
Dec
(6) |
2017 |
Jan
|
Feb
(3) |
Mar
(24) |
Apr
(9) |
May
(3) |
Jun
(1) |
Jul
(18) |
Aug
(4) |
Sep
|
Oct
(7) |
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(1) |
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
(4) |
2020 |
Jan
(9) |
Feb
(25) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: David C. <dav...@gm...> - 2021-07-23 16:25:23
|
I think the need will exist for at least another 5 years. On Fri, Jul 23, 2021 at 8:51 AM Ken Goldman <kgo...@us...> wrote: > > On Wed, 14 Jul 2021, Debora Velarde Babb wrote: > >> We would like to hear from users that have applications that are > >> dependent on TPM 1.2. This will be used to help determine whether or > >> not to include TrouSerS in newer Linux distro releases. If you do have > >> a continued need for trousers, but downloading it from sourceforge and > >> building it yourself is sufficient for your needs, that would also be > >> helpful to know. > > My guess is that the end will come for trousers when the distros move > to a version of openssl that removes the low level APIs. > > Even now, when they're deprecated, some functions fail. So > some porting will be required for openssl 3.0 > > > _______________________________________________ > TrouSerS-users mailing list > Tro...@li... > https://lists.sourceforge.net/lists/listinfo/trousers-users > |
From: Ken G. <kgo...@us...> - 2021-07-23 12:51:18
|
> On Wed, 14 Jul 2021, Debora Velarde Babb wrote: >> We would like to hear from users that have applications that are >> dependent on TPM 1.2. This will be used to help determine whether or >> not to include TrouSerS in newer Linux distro releases. If you do have >> a continued need for trousers, but downloading it from sourceforge and >> building it yourself is sufficient for your needs, that would also be >> helpful to know. My guess is that the end will come for trousers when the distros move to a version of openssl that removes the low level APIs. Even now, when they're deprecated, some functions fail. So some porting will be required for openssl 3.0 |
From: Timo L. <tim...@ik...> - 2021-07-15 08:30:07
|
Hi, On Wed, 14 Jul 2021, Debora Velarde Babb wrote: > We would like to hear from users that have applications that are > dependent on TPM 1.2. This will be used to help determine whether or > not to include TrouSerS in newer Linux distro releases. If you do have > a continued need for trousers, but downloading it from sourceforge and > building it yourself is sufficient for your needs, that would also be > helpful to know. I can say that compiling software manually like that is a major problem for commercial users. The benefits for having TPM 1.2 support in the distributions is quite clear in my opinion as they don't need to review the licensing terms on their own, handle updates manually and can report packaging bugs. Overall this results in more secure solutions. Now that TPM usage is slowly gathering momentum itwould be really shame to drop the support before we really have TPM 2.0 on most existing systems. I'm packaging tboot for Debian. I could perhaps also help with Debian packaging of trousers if needed. -Timo |
From: Debora V. B. <de...@li...> - 2021-07-14 22:13:02
|
Greetings, We are trying to gauge the continued interest/need for trousers in newer Linux distro versions. TrouSerS only supports TPM 1.2. Most newer systems now have TPM 2.0. There are multiple software stack options for the TPM 2.0. One such option being the IBM TSS project: https://sourceforge.net/projects/ibmtpm20tss/ We would like to hear from users that have applications that are dependent on TPM 1.2. This will be used to help determine whether or not to include TrouSerS in newer Linux distro releases. If you do have a continued need for trousers, but downloading it from sourceforge and building it yourself is sufficient for your needs, that would also be helpful to know. Thank you, Debora Debora Velarde Babb IBM Linux Security Team de...@li... |
From: Debora V. B. <de...@li...> - 2020-11-03 13:35:43
|
A new version of TrouSerS-0.3.15 and tpm-tools-1.3.9.2 is now available for download. Changes to this version include: * Fixes for security issues that existed if the tcsd is started by root instead of the tss user * Fixed multiple potential instances of use after free memory handling * Replacing the use of _no_optimize with asm memory barrier * Removed unused global variables which caused build issue on some distros * tpm-tools support for PCRs 15-23 for sealing data * tpm-tools fix for building with OpenSSL 1.1 * Manpage cleanup Many thanks to everyone who contributed! Debora Velarde Babb IBM Linux Security |
From: Sam J. <sam...@go...> - 2020-02-26 10:53:55
|
My understanding from earlier similar questions is that to seal/unseal data using tspi_data_seal/unseal I need to have ownership of the TPM, a key wrapped by the root storage key, and an ENCDATA object with the same secret as the key, but my program is still failing on authsess_xsap_verify within the unseal algorithm after having successfully sealed the data. I am not however getting the Auth failed error code, just error code 1. On Tue, 25 Feb 2020 at 20:20, Sam Jenkins <sam...@go...> wrote: > Just to clarify, Im aware that the problem appears to be to do with an > OSAP session not being properly setup, so what do I need to do for it to be > setup properly? > > On Tue, 25 Feb 2020 at 20:12, Sam Jenkins <sam...@go...> > wrote: > >> hi, >> could somone please help me with this? I've been trying to get this >> working since late december and havn't been able to. I've successfully >> sealed the data to the TPM using tspi_data_seal, but tspi_data_unseal if >> failing. >> >> in debugging the I've found that it fails at authsess_xsap_verify, and it >> seems to be something to do with the authorization session, I havn't been >> able to figure out any more detail than that. >> >> I've included my code below, if anyone can see what Im missing in terms >> of authorization before the call to tspi_data_unseal it really would be >> greatly appreciated. Im not sure where else to ask about this. And looking >> at the examples of how its used in tpm_tools and in other places (guide to >> trusted computing etc.) have got me this far but no further. >> >> #include "test.h" >> #include <stddef.h> >> #include <stdio.h> >> #include <stdlib.h> >> #include <string.h> >> #include <tss/platform.h> >> #include <tss/tss_structs.h> >> #include <tss/tss_typedef.h> >> #include <unistd.h> >> >> int main() { >> TSS_HPCRS pcrs; >> UINT32 pcrsToUse[8] = {0, 1, 2, 3, 4, 5, 6, 7}; >> UINT32 numOfPcrs = 8; >> createKey(); >> CreatePcrs(numOfPcrs, pcrsToUse, &pcrs); >> >> BYTE outBuffer[400] = {0}; >> BYTE *inBuffer = readFile(); >> >> SealData(kHandle, pcrs, inSize, inBuffer, &outSize, outBuffer); >> printf("sealed out %u\n", outSize); >> // unsealData(kHandle, inSize, inBuffer, &outSize, outBuffer); >> >> // Tspi_Context_FreeMemory(hContext, NULL); >> Tspi_Context_Close(hContext); >> free(inBuffer); >> printf("result = %u\n", result); >> return 0; >> } >> >> BYTE *readFile() { >> BYTE *inBuffer; >> >> FILE *fin, *fout; >> fin = fopen("/home/bham/Desktop/keyfile", "rb"); >> fseek(fin, 0, SEEK_END); >> inSize = ftell(fin); >> if (inSize < 400) { >> inBuffer = malloc(inSize); >> } else { >> return NULL; >> } >> outSize = inSize + 103; >> fseek(fin, 0, SEEK_SET); >> fread(inBuffer, inSize, 1, fin); >> fclose(fin); >> return inBuffer; >> } >> >> TSS_HKEY initialSetup(TSS_UUID SRK_UUID) { >> TSS_HPOLICY hOwnerPolicy; >> >> TSS_HKEY hSRK; >> Tspi_Context_Create(&hContext); >> Tspi_SetAttribUint32(hContext, TSS_TSPATTRIB_CONTEXT_VERSION_MODE, 0, >> TSS_TSPATTRIB_CONTEXT_VERSION_V1_2); >> Tspi_Context_Connect(hContext, NULL); >> // set self to owner >> Tspi_Context_GetTpmObject(hContext, &hTPM); >> Tspi_GetPolicyObject(hTPM, TSS_POLICY_USAGE, &hOwnerPolicy); >> Tspi_Policy_SetSecret(hOwnerPolicy, TSS_SECRET_MODE_SHA1, 4, "bham"); >> >> Tspi_Context_LoadKeyByUUID(hContext, TSS_PS_TYPE_SYSTEM, SRK_UUID, >> &hSRK); >> // set SRK secret to well known secret >> Tspi_GetPolicyObject(hSRK, TSS_POLICY_USAGE, &hOwnerPolicy); >> Tspi_Policy_SetSecret(hOwnerPolicy, TSS_SECRET_MODE_SHA1, 20, wks); >> return hSRK; >> } >> >> TSS_HKEY newKey(TSS_UUID key_uuid, TSS_UUID SRK_UUID, TSS_HKEY hSRK, >> TSS_HKEY hKey) { >> TSS_HPOLICY policy; >> // set a secret on the key, this will be used as setting a password >> once the >> // seal/unseal is working >> Tspi_Context_CreateObject(hContext, TSS_OBJECT_TYPE_POLICY, >> TSS_POLICY_USAGE, >> &policy); >> Tspi_Policy_SetSecret(policy, TSS_SECRET_MODE_PLAIN, 4, "bham"); >> Tspi_Policy_AssignToObject(policy, hKey); >> >> // create the key and register it to storage >> result = Tspi_Key_CreateKey(hKey, hSRK, 0); >> result = Tspi_Context_RegisterKey(hContext, hKey, TSS_PS_TYPE_SYSTEM, >> key_uuid, TSS_PS_TYPE_SYSTEM, >> SRK_UUID); >> >> result = Tspi_Key_LoadKey(hKey, hSRK); >> return hKey; >> } >> >> int createKey() { >> TSS_FLAG initFlags; >> TSS_HKEY hSRK, hKey; >> TSS_UUID key_uuid = {7}, SRK_UUID = TSS_UUID_SRK; >> >> hSRK = initialSetup(SRK_UUID); >> >> initFlags = TSS_KEY_TYPE_STORAGE | TSS_KEY_SIZE_2048 | >> TSS_KEY_NOT_MIGRATABLE; >> Tspi_Context_CreateObject(hContext, TSS_OBJECT_TYPE_RSAKEY, initFlags, >> &hKey); >> >> // check that a key has been created, otherwise make one. >> if (!(TSS_SUCCESS == Tspi_Context_GetKeyByUUID(hContext, >> TSS_PS_TYPE_SYSTEM, >> key_uuid, &kHandle))) { >> kHandle = newKey(key_uuid, SRK_UUID, hSRK, hKey); >> printf("key created result = %u\n", result); >> } else { >> result = Tspi_Key_LoadKey(kHandle, hSRK); >> } >> printf("key premade result = %u\n", result); >> return 0; >> } >> >> int SealData(TSS_HKEY hKey, TSS_HPCRS hPcrs, UINT32 in_size, BYTE *in, >> UINT32 *out_size, BYTE *out) { >> TSS_HENCDATA hEncData; >> UINT32 keySize, tmp_out_size; >> BYTE *tmp_out; >> /* Create the encrypted data object in the TSP */ >> Tspi_Context_CreateObject(hContext, TSS_OBJECT_TYPE_ENCDATA, >> TSS_ENCDATA_SEAL, >> &hEncData); >> Tspi_GetAttribUint32(hKey, TSS_TSPATTRIB_KEY_INFO, >> TSS_TSPATTRIB_KEYINFO_SIZE, >> &keySize); >> >> TSS_HPOLICY policy; >> >> Tspi_Context_CreateObject(hContext, TSS_OBJECT_TYPE_POLICY, >> TSS_POLICY_USAGE, >> &policy); >> Tspi_Policy_SetSecret(policy, TSS_SECRET_MODE_PLAIN, 4, "bham"); >> >> /* Make sure the data is small enough to be bound by this* >> key,taking into account the OAEP padding size (38) and* the >> size of the TPM_SEALED_DATA structure (65) */ >> if (in_size > 153) { >> printf("Data to be encrypted is too big !\n"); >> return -1; >> } >> >> result = Tspi_Data_Seal(hEncData, hKey, in_size, in, hPcrs); >> >> printf("result of seal = %u\n", result); >> // This is the test unseal I'm using directly afterwoods, wont be here >> in >> // finished program. >> BYTE *outputholder; >> printf("result of policy =%u\n", result); >> result = Tspi_Data_Unseal(hEncData, hKey, &in_size, &outputholder); >> printf("result of unseal: %u\n", result); >> FILE *fout; >> fout = fopen("/home/bham/Desktop/Temp Work/testout", "wb"); >> write(fileno(fout), outputholder, *out_size); >> fclose(fout); >> >> /* Now hEncData contains an encrypted blob, let’s extract * it >> NORMAL CODE RESUMES HERE*/ >> Tspi_GetAttribData(hEncData, TSS_TSPATTRIB_ENCDATA_BLOB, >> TSS_TSPATTRIB_ENCDATABLOB_BLOB, &tmp_out_size, >> &tmp_out); >> printf("output of get data: %u\n", result); >> >> printf("result = %i\n", result); >> printf("%u = tmp_out_size\n", tmp_out_size); >> printf("%s = tmp_out\n", tmp_out); >> >> memcpy(out, tmp_out, tmp_out_size); >> *out_size = tmp_out_size; >> >> printf("out is :%s\n", out); >> /* Free the blob returned by the TSP */ >> Tspi_Context_FreeMemory(hContext, tmp_out); >> /* Close the encrypted data object, it will no longer * be used */ >> Tspi_Context_CloseObject(hContext, hEncData); >> return 0; >> } >> >> int CreatePcrs(UINT32 num_pcrs, UINT32 *pcrs, TSS_HPCRS *hPcrs) { >> UINT32 numPcrs, subCap, i; >> UINT32 ulPcrValueLength; >> BYTE *rgbPcrValue, *rgbNumPcrs; >> Tspi_Context_CreateObject(hContext, TSS_OBJECT_TYPE_PCRS, 0, hPcrs); >> // Retrieve number of PCRs from the TPM >> subCap = TSS_TPMCAP_PROP_PCR; >> Tspi_TPM_GetCapability(hTPM, TSS_TPMCAP_PROPERTY, sizeof(UINT32), >> (BYTE *)&subCap, &ulPcrValueLength, &rgbNumPcrs); >> numPcrs = *(UINT32 *)rgbNumPcrs; >> Tspi_Context_FreeMemory(hContext, rgbNumPcrs); >> for (i = 0; i < num_pcrs; i++) { >> if (pcrs[i] >= numPcrs) { >> printf("PCR value %u is too big !\n", pcrs[i]); >> Tspi_Context_CloseObject(hContext, *hPcrs); >> return -1; >> } >> Tspi_TPM_PcrRead(hTPM, pcrs[i], &ulPcrValueLength, &rgbPcrValue); >> Tspi_PcrComposite_SetPcrValue(*hPcrs, pcrs[i], ulPcrValueLength, >> rgbPcrValue); >> Tspi_Context_FreeMemory(hContext, rgbPcrValue); >> } >> return 0; >> } >> >> and yes Im aware of flaws in here like fixed and rubbish passwords, this >> is all just simple test stuff while I get it working. >> > > > -- > hello > -- hello |
From: Sam J. <sam...@go...> - 2020-02-25 20:20:26
|
Just to clarify, Im aware that the problem appears to be to do with an OSAP session not being properly setup, so what do I need to do for it to be setup properly? On Tue, 25 Feb 2020 at 20:12, Sam Jenkins <sam...@go...> wrote: > hi, > could somone please help me with this? I've been trying to get this > working since late december and havn't been able to. I've successfully > sealed the data to the TPM using tspi_data_seal, but tspi_data_unseal if > failing. > > in debugging the I've found that it fails at authsess_xsap_verify, and it > seems to be something to do with the authorization session, I havn't been > able to figure out any more detail than that. > > I've included my code below, if anyone can see what Im missing in terms of > authorization before the call to tspi_data_unseal it really would be > greatly appreciated. Im not sure where else to ask about this. And looking > at the examples of how its used in tpm_tools and in other places (guide to > trusted computing etc.) have got me this far but no further. > > #include "test.h" > #include <stddef.h> > #include <stdio.h> > #include <stdlib.h> > #include <string.h> > #include <tss/platform.h> > #include <tss/tss_structs.h> > #include <tss/tss_typedef.h> > #include <unistd.h> > > int main() { > TSS_HPCRS pcrs; > UINT32 pcrsToUse[8] = {0, 1, 2, 3, 4, 5, 6, 7}; > UINT32 numOfPcrs = 8; > createKey(); > CreatePcrs(numOfPcrs, pcrsToUse, &pcrs); > > BYTE outBuffer[400] = {0}; > BYTE *inBuffer = readFile(); > > SealData(kHandle, pcrs, inSize, inBuffer, &outSize, outBuffer); > printf("sealed out %u\n", outSize); > // unsealData(kHandle, inSize, inBuffer, &outSize, outBuffer); > > // Tspi_Context_FreeMemory(hContext, NULL); > Tspi_Context_Close(hContext); > free(inBuffer); > printf("result = %u\n", result); > return 0; > } > > BYTE *readFile() { > BYTE *inBuffer; > > FILE *fin, *fout; > fin = fopen("/home/bham/Desktop/keyfile", "rb"); > fseek(fin, 0, SEEK_END); > inSize = ftell(fin); > if (inSize < 400) { > inBuffer = malloc(inSize); > } else { > return NULL; > } > outSize = inSize + 103; > fseek(fin, 0, SEEK_SET); > fread(inBuffer, inSize, 1, fin); > fclose(fin); > return inBuffer; > } > > TSS_HKEY initialSetup(TSS_UUID SRK_UUID) { > TSS_HPOLICY hOwnerPolicy; > > TSS_HKEY hSRK; > Tspi_Context_Create(&hContext); > Tspi_SetAttribUint32(hContext, TSS_TSPATTRIB_CONTEXT_VERSION_MODE, 0, > TSS_TSPATTRIB_CONTEXT_VERSION_V1_2); > Tspi_Context_Connect(hContext, NULL); > // set self to owner > Tspi_Context_GetTpmObject(hContext, &hTPM); > Tspi_GetPolicyObject(hTPM, TSS_POLICY_USAGE, &hOwnerPolicy); > Tspi_Policy_SetSecret(hOwnerPolicy, TSS_SECRET_MODE_SHA1, 4, "bham"); > > Tspi_Context_LoadKeyByUUID(hContext, TSS_PS_TYPE_SYSTEM, SRK_UUID, > &hSRK); > // set SRK secret to well known secret > Tspi_GetPolicyObject(hSRK, TSS_POLICY_USAGE, &hOwnerPolicy); > Tspi_Policy_SetSecret(hOwnerPolicy, TSS_SECRET_MODE_SHA1, 20, wks); > return hSRK; > } > > TSS_HKEY newKey(TSS_UUID key_uuid, TSS_UUID SRK_UUID, TSS_HKEY hSRK, > TSS_HKEY hKey) { > TSS_HPOLICY policy; > // set a secret on the key, this will be used as setting a password once > the > // seal/unseal is working > Tspi_Context_CreateObject(hContext, TSS_OBJECT_TYPE_POLICY, > TSS_POLICY_USAGE, > &policy); > Tspi_Policy_SetSecret(policy, TSS_SECRET_MODE_PLAIN, 4, "bham"); > Tspi_Policy_AssignToObject(policy, hKey); > > // create the key and register it to storage > result = Tspi_Key_CreateKey(hKey, hSRK, 0); > result = Tspi_Context_RegisterKey(hContext, hKey, TSS_PS_TYPE_SYSTEM, > key_uuid, TSS_PS_TYPE_SYSTEM, > SRK_UUID); > > result = Tspi_Key_LoadKey(hKey, hSRK); > return hKey; > } > > int createKey() { > TSS_FLAG initFlags; > TSS_HKEY hSRK, hKey; > TSS_UUID key_uuid = {7}, SRK_UUID = TSS_UUID_SRK; > > hSRK = initialSetup(SRK_UUID); > > initFlags = TSS_KEY_TYPE_STORAGE | TSS_KEY_SIZE_2048 | > TSS_KEY_NOT_MIGRATABLE; > Tspi_Context_CreateObject(hContext, TSS_OBJECT_TYPE_RSAKEY, initFlags, > &hKey); > > // check that a key has been created, otherwise make one. > if (!(TSS_SUCCESS == Tspi_Context_GetKeyByUUID(hContext, > TSS_PS_TYPE_SYSTEM, > key_uuid, &kHandle))) { > kHandle = newKey(key_uuid, SRK_UUID, hSRK, hKey); > printf("key created result = %u\n", result); > } else { > result = Tspi_Key_LoadKey(kHandle, hSRK); > } > printf("key premade result = %u\n", result); > return 0; > } > > int SealData(TSS_HKEY hKey, TSS_HPCRS hPcrs, UINT32 in_size, BYTE *in, > UINT32 *out_size, BYTE *out) { > TSS_HENCDATA hEncData; > UINT32 keySize, tmp_out_size; > BYTE *tmp_out; > /* Create the encrypted data object in the TSP */ > Tspi_Context_CreateObject(hContext, TSS_OBJECT_TYPE_ENCDATA, > TSS_ENCDATA_SEAL, > &hEncData); > Tspi_GetAttribUint32(hKey, TSS_TSPATTRIB_KEY_INFO, > TSS_TSPATTRIB_KEYINFO_SIZE, > &keySize); > > TSS_HPOLICY policy; > > Tspi_Context_CreateObject(hContext, TSS_OBJECT_TYPE_POLICY, > TSS_POLICY_USAGE, > &policy); > Tspi_Policy_SetSecret(policy, TSS_SECRET_MODE_PLAIN, 4, "bham"); > > /* Make sure the data is small enough to be bound by this* > key,taking into account the OAEP padding size (38) and* the > size of the TPM_SEALED_DATA structure (65) */ > if (in_size > 153) { > printf("Data to be encrypted is too big !\n"); > return -1; > } > > result = Tspi_Data_Seal(hEncData, hKey, in_size, in, hPcrs); > > printf("result of seal = %u\n", result); > // This is the test unseal I'm using directly afterwoods, wont be here in > // finished program. > BYTE *outputholder; > printf("result of policy =%u\n", result); > result = Tspi_Data_Unseal(hEncData, hKey, &in_size, &outputholder); > printf("result of unseal: %u\n", result); > FILE *fout; > fout = fopen("/home/bham/Desktop/Temp Work/testout", "wb"); > write(fileno(fout), outputholder, *out_size); > fclose(fout); > > /* Now hEncData contains an encrypted blob, let’s extract * it > NORMAL CODE RESUMES HERE*/ > Tspi_GetAttribData(hEncData, TSS_TSPATTRIB_ENCDATA_BLOB, > TSS_TSPATTRIB_ENCDATABLOB_BLOB, &tmp_out_size, > &tmp_out); > printf("output of get data: %u\n", result); > > printf("result = %i\n", result); > printf("%u = tmp_out_size\n", tmp_out_size); > printf("%s = tmp_out\n", tmp_out); > > memcpy(out, tmp_out, tmp_out_size); > *out_size = tmp_out_size; > > printf("out is :%s\n", out); > /* Free the blob returned by the TSP */ > Tspi_Context_FreeMemory(hContext, tmp_out); > /* Close the encrypted data object, it will no longer * be used */ > Tspi_Context_CloseObject(hContext, hEncData); > return 0; > } > > int CreatePcrs(UINT32 num_pcrs, UINT32 *pcrs, TSS_HPCRS *hPcrs) { > UINT32 numPcrs, subCap, i; > UINT32 ulPcrValueLength; > BYTE *rgbPcrValue, *rgbNumPcrs; > Tspi_Context_CreateObject(hContext, TSS_OBJECT_TYPE_PCRS, 0, hPcrs); > // Retrieve number of PCRs from the TPM > subCap = TSS_TPMCAP_PROP_PCR; > Tspi_TPM_GetCapability(hTPM, TSS_TPMCAP_PROPERTY, sizeof(UINT32), > (BYTE *)&subCap, &ulPcrValueLength, &rgbNumPcrs); > numPcrs = *(UINT32 *)rgbNumPcrs; > Tspi_Context_FreeMemory(hContext, rgbNumPcrs); > for (i = 0; i < num_pcrs; i++) { > if (pcrs[i] >= numPcrs) { > printf("PCR value %u is too big !\n", pcrs[i]); > Tspi_Context_CloseObject(hContext, *hPcrs); > return -1; > } > Tspi_TPM_PcrRead(hTPM, pcrs[i], &ulPcrValueLength, &rgbPcrValue); > Tspi_PcrComposite_SetPcrValue(*hPcrs, pcrs[i], ulPcrValueLength, > rgbPcrValue); > Tspi_Context_FreeMemory(hContext, rgbPcrValue); > } > return 0; > } > > and yes Im aware of flaws in here like fixed and rubbish passwords, this > is all just simple test stuff while I get it working. > -- hello |
From: Sam J. <sam...@go...> - 2020-02-25 20:12:35
|
hi, could somone please help me with this? I've been trying to get this working since late december and havn't been able to. I've successfully sealed the data to the TPM using tspi_data_seal, but tspi_data_unseal if failing. in debugging the I've found that it fails at authsess_xsap_verify, and it seems to be something to do with the authorization session, I havn't been able to figure out any more detail than that. I've included my code below, if anyone can see what Im missing in terms of authorization before the call to tspi_data_unseal it really would be greatly appreciated. Im not sure where else to ask about this. And looking at the examples of how its used in tpm_tools and in other places (guide to trusted computing etc.) have got me this far but no further. #include "test.h" #include <stddef.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <tss/platform.h> #include <tss/tss_structs.h> #include <tss/tss_typedef.h> #include <unistd.h> int main() { TSS_HPCRS pcrs; UINT32 pcrsToUse[8] = {0, 1, 2, 3, 4, 5, 6, 7}; UINT32 numOfPcrs = 8; createKey(); CreatePcrs(numOfPcrs, pcrsToUse, &pcrs); BYTE outBuffer[400] = {0}; BYTE *inBuffer = readFile(); SealData(kHandle, pcrs, inSize, inBuffer, &outSize, outBuffer); printf("sealed out %u\n", outSize); // unsealData(kHandle, inSize, inBuffer, &outSize, outBuffer); // Tspi_Context_FreeMemory(hContext, NULL); Tspi_Context_Close(hContext); free(inBuffer); printf("result = %u\n", result); return 0; } BYTE *readFile() { BYTE *inBuffer; FILE *fin, *fout; fin = fopen("/home/bham/Desktop/keyfile", "rb"); fseek(fin, 0, SEEK_END); inSize = ftell(fin); if (inSize < 400) { inBuffer = malloc(inSize); } else { return NULL; } outSize = inSize + 103; fseek(fin, 0, SEEK_SET); fread(inBuffer, inSize, 1, fin); fclose(fin); return inBuffer; } TSS_HKEY initialSetup(TSS_UUID SRK_UUID) { TSS_HPOLICY hOwnerPolicy; TSS_HKEY hSRK; Tspi_Context_Create(&hContext); Tspi_SetAttribUint32(hContext, TSS_TSPATTRIB_CONTEXT_VERSION_MODE, 0, TSS_TSPATTRIB_CONTEXT_VERSION_V1_2); Tspi_Context_Connect(hContext, NULL); // set self to owner Tspi_Context_GetTpmObject(hContext, &hTPM); Tspi_GetPolicyObject(hTPM, TSS_POLICY_USAGE, &hOwnerPolicy); Tspi_Policy_SetSecret(hOwnerPolicy, TSS_SECRET_MODE_SHA1, 4, "bham"); Tspi_Context_LoadKeyByUUID(hContext, TSS_PS_TYPE_SYSTEM, SRK_UUID, &hSRK); // set SRK secret to well known secret Tspi_GetPolicyObject(hSRK, TSS_POLICY_USAGE, &hOwnerPolicy); Tspi_Policy_SetSecret(hOwnerPolicy, TSS_SECRET_MODE_SHA1, 20, wks); return hSRK; } TSS_HKEY newKey(TSS_UUID key_uuid, TSS_UUID SRK_UUID, TSS_HKEY hSRK, TSS_HKEY hKey) { TSS_HPOLICY policy; // set a secret on the key, this will be used as setting a password once the // seal/unseal is working Tspi_Context_CreateObject(hContext, TSS_OBJECT_TYPE_POLICY, TSS_POLICY_USAGE, &policy); Tspi_Policy_SetSecret(policy, TSS_SECRET_MODE_PLAIN, 4, "bham"); Tspi_Policy_AssignToObject(policy, hKey); // create the key and register it to storage result = Tspi_Key_CreateKey(hKey, hSRK, 0); result = Tspi_Context_RegisterKey(hContext, hKey, TSS_PS_TYPE_SYSTEM, key_uuid, TSS_PS_TYPE_SYSTEM, SRK_UUID); result = Tspi_Key_LoadKey(hKey, hSRK); return hKey; } int createKey() { TSS_FLAG initFlags; TSS_HKEY hSRK, hKey; TSS_UUID key_uuid = {7}, SRK_UUID = TSS_UUID_SRK; hSRK = initialSetup(SRK_UUID); initFlags = TSS_KEY_TYPE_STORAGE | TSS_KEY_SIZE_2048 | TSS_KEY_NOT_MIGRATABLE; Tspi_Context_CreateObject(hContext, TSS_OBJECT_TYPE_RSAKEY, initFlags, &hKey); // check that a key has been created, otherwise make one. if (!(TSS_SUCCESS == Tspi_Context_GetKeyByUUID(hContext, TSS_PS_TYPE_SYSTEM, key_uuid, &kHandle))) { kHandle = newKey(key_uuid, SRK_UUID, hSRK, hKey); printf("key created result = %u\n", result); } else { result = Tspi_Key_LoadKey(kHandle, hSRK); } printf("key premade result = %u\n", result); return 0; } int SealData(TSS_HKEY hKey, TSS_HPCRS hPcrs, UINT32 in_size, BYTE *in, UINT32 *out_size, BYTE *out) { TSS_HENCDATA hEncData; UINT32 keySize, tmp_out_size; BYTE *tmp_out; /* Create the encrypted data object in the TSP */ Tspi_Context_CreateObject(hContext, TSS_OBJECT_TYPE_ENCDATA, TSS_ENCDATA_SEAL, &hEncData); Tspi_GetAttribUint32(hKey, TSS_TSPATTRIB_KEY_INFO, TSS_TSPATTRIB_KEYINFO_SIZE, &keySize); TSS_HPOLICY policy; Tspi_Context_CreateObject(hContext, TSS_OBJECT_TYPE_POLICY, TSS_POLICY_USAGE, &policy); Tspi_Policy_SetSecret(policy, TSS_SECRET_MODE_PLAIN, 4, "bham"); /* Make sure the data is small enough to be bound by this* key,taking into account the OAEP padding size (38) and* the size of the TPM_SEALED_DATA structure (65) */ if (in_size > 153) { printf("Data to be encrypted is too big !\n"); return -1; } result = Tspi_Data_Seal(hEncData, hKey, in_size, in, hPcrs); printf("result of seal = %u\n", result); // This is the test unseal I'm using directly afterwoods, wont be here in // finished program. BYTE *outputholder; printf("result of policy =%u\n", result); result = Tspi_Data_Unseal(hEncData, hKey, &in_size, &outputholder); printf("result of unseal: %u\n", result); FILE *fout; fout = fopen("/home/bham/Desktop/Temp Work/testout", "wb"); write(fileno(fout), outputholder, *out_size); fclose(fout); /* Now hEncData contains an encrypted blob, let’s extract * it NORMAL CODE RESUMES HERE*/ Tspi_GetAttribData(hEncData, TSS_TSPATTRIB_ENCDATA_BLOB, TSS_TSPATTRIB_ENCDATABLOB_BLOB, &tmp_out_size, &tmp_out); printf("output of get data: %u\n", result); printf("result = %i\n", result); printf("%u = tmp_out_size\n", tmp_out_size); printf("%s = tmp_out\n", tmp_out); memcpy(out, tmp_out, tmp_out_size); *out_size = tmp_out_size; printf("out is :%s\n", out); /* Free the blob returned by the TSP */ Tspi_Context_FreeMemory(hContext, tmp_out); /* Close the encrypted data object, it will no longer * be used */ Tspi_Context_CloseObject(hContext, hEncData); return 0; } int CreatePcrs(UINT32 num_pcrs, UINT32 *pcrs, TSS_HPCRS *hPcrs) { UINT32 numPcrs, subCap, i; UINT32 ulPcrValueLength; BYTE *rgbPcrValue, *rgbNumPcrs; Tspi_Context_CreateObject(hContext, TSS_OBJECT_TYPE_PCRS, 0, hPcrs); // Retrieve number of PCRs from the TPM subCap = TSS_TPMCAP_PROP_PCR; Tspi_TPM_GetCapability(hTPM, TSS_TPMCAP_PROPERTY, sizeof(UINT32), (BYTE *)&subCap, &ulPcrValueLength, &rgbNumPcrs); numPcrs = *(UINT32 *)rgbNumPcrs; Tspi_Context_FreeMemory(hContext, rgbNumPcrs); for (i = 0; i < num_pcrs; i++) { if (pcrs[i] >= numPcrs) { printf("PCR value %u is too big !\n", pcrs[i]); Tspi_Context_CloseObject(hContext, *hPcrs); return -1; } Tspi_TPM_PcrRead(hTPM, pcrs[i], &ulPcrValueLength, &rgbPcrValue); Tspi_PcrComposite_SetPcrValue(*hPcrs, pcrs[i], ulPcrValueLength, rgbPcrValue); Tspi_Context_FreeMemory(hContext, rgbPcrValue); } return 0; } and yes Im aware of flaws in here like fixed and rubbish passwords, this is all just simple test stuff while I get it working. |
From: Sam J. <sam...@go...> - 2020-02-24 15:31:11
|
> At this point, you need a trousers person to help. I know the > TPM side well, but not the trousers TSS. That would be why I'm email the trousers users mailing list yes... On Mon, 24 Feb 2020 at 15:09, Ken Goldman <kgo...@us...> wrote: > On 2/24/2020 10:02 AM, Sam Jenkins via TrouSerS-users wrote: > > Ok, I understand that unseal requires authorisation, what Im unsure of > > is how to supply the authorisation. I have all they keys setup, and I am > > the owner, so the authorization Im missing is the authorization of the > > object, trying to set a policy on the object just leads to unseal > > telling me that "No secret information for addressed policy object". > > Basically I know I'm missing something, but not sure what. Both "A > > Practical Guide to Secure Computing" and the TCG introduction to using > > the TSS that I was able to find don't show a step of a policy to the > > HENCDATA, and doing myself hasn't worked, so how am I meant to be > > supplying authorisation data to the object before calling unseal? > > "am the owner" or having the owner authorization should not matter > for seal or unseal. > > At this point, you need a trousers person to help. I know the > TPM side well, but not the trousers TSS. > > > > _______________________________________________ > TrouSerS-users mailing list > Tro...@li... > https://lists.sourceforge.net/lists/listinfo/trousers-users > -- hello |
From: Ken G. <kgo...@us...> - 2020-02-24 15:08:52
|
On 2/24/2020 10:02 AM, Sam Jenkins via TrouSerS-users wrote: > Ok, I understand that unseal requires authorisation, what Im unsure of > is how to supply the authorisation. I have all they keys setup, and I am > the owner, so the authorization Im missing is the authorization of the > object, trying to set a policy on the object just leads to unseal > telling me that "No secret information for addressed policy object". > Basically I know I'm missing something, but not sure what. Both "A > Practical Guide to Secure Computing" and the TCG introduction to using > the TSS that I was able to find don't show a step of a policy to the > HENCDATA, and doing myself hasn't worked, so how am I meant to be > supplying authorisation data to the object before calling unseal? "am the owner" or having the owner authorization should not matter for seal or unseal. At this point, you need a trousers person to help. I know the TPM side well, but not the trousers TSS. |
From: Sam J. <sam...@go...> - 2020-02-24 15:02:39
|
Ok, I understand that unseal requires authorisation, what Im unsure of is how to supply the authorisation. I have all they keys setup, and I am the owner, so the authorization Im missing is the authorization of the object, trying to set a policy on the object just leads to unseal telling me that "No secret information for addressed policy object". Basically I know I'm missing something, but not sure what. Both "A Practical Guide to Secure Computing" and the TCG introduction to using the TSS that I was able to find don't show a step of a policy to the HENCDATA, and doing myself hasn't worked, so how am I meant to be supplying authorisation data to the object before calling unseal? On Mon, 24 Feb 2020 at 13:49, Ken Goldman <kgo...@us...> wrote: > On 2/23/2020 9:04 AM, Sam Jenkins via TrouSerS-users wrote: > > Hi, > > If the problem is not having the authorisation of the object how do I > > solve this? > > Unseal requires authorization. If the caller does not supply > the correct authorization, the TPM will not return the secret. > > > If no policy was set on the object shouldn't it by default use the > > authorisation of the context? Because setting that to the owner doesn't > > seem to make a difference? > > Unseal requires the authorization of the object. The TPM owner is > not like a Unix root that can do anything. > > > -- hello |
From: Ken G. <kgo...@us...> - 2020-02-24 13:49:32
|
On 2/23/2020 9:04 AM, Sam Jenkins via TrouSerS-users wrote: > Hi, > If the problem is not having the authorisation of the object how do I > solve this? Unseal requires authorization. If the caller does not supply the correct authorization, the TPM will not return the secret. > If no policy was set on the object shouldn't it by default use the > authorisation of the context? Because setting that to the owner doesn't > seem to make a difference? Unseal requires the authorization of the object. The TPM owner is not like a Unix root that can do anything. |
From: Sam J. <sam...@go...> - 2020-02-23 14:05:14
|
Hi, If the problem is not having the authorisation of the object how do I solve this? If no policy was set on the object shouldn't it by default use the authorisation of the context? Because setting that to the owner doesnt seem to make a difference? And setting the policy of the encdata itself merely changes the error to "No secret information for addressed policy object", despite having just set the secret |
From: Kenneth G. <kgo...@us...> - 2020-02-19 13:00:15
|
<font face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size="2"><span></span>>from my debugging I'm now fairly certain that I've missed a stage of<br>>authorisation when setting up for the call to unseal (which<br>>confusingly<br>>enough, requires more authentication than seal) would anyone quickly<br>>mind<br>>going through how to setup a session with authorisation to unseal<br>>data?<br>>Thanks<br><div>>Sam Jenkins</div><div><br></div><div>Seal requires one authorization, that of the parent.</div><div><br></div><div>Unseal requires two authorizations, that of the parent and that of the</div><div>sealed object.</div><div><br></div><div>I.e., the object's authorization is not required to seal, only to unseal.<br></div><br></font><BR> |
From: Sam J. <sam...@go...> - 2020-02-19 10:19:35
|
Hi, from my debugging im now fairly certain that I've missed a stage of authorisation when setting up for the call to unseal (which confusingly enough, requires more authentication than seal) would anyone quickly mind going through how to setup a session with authorisation to unseal data? Thanks Sam Jenkins |
From: Ken G. <kgo...@us...> - 2020-02-10 15:55:13
|
On 2/7/2020 2:03 PM, Martin Galvan wrote: > crypto/openssl/rsa.c: In function ‘Trspi_RSA_Encrypt’: > crypto/openssl/rsa.c:71:5: error: dereferencing pointer to incomplete > type ‘RSA {aka struct rsa_st}’ > rsa->n = BN_bin2bn(publicKey, keysize, rsa->n); > ^~ Recent (early 2018) openssl releases made many structures (e.g. RSA) opaque. Software cannot dereference them directly, but must use getter methods. I don't know if trousers has been ported to recent openssl. The older versions are out of support and should not be used. |
From: Sam J. <sam...@go...> - 2020-02-10 15:24:36
|
If I am doing anything odd with the session or password, its not deliberate, unless I've made a mistake somewhere in the earlier code, it shouldn't be doing anything particularly odd. On Mon, 10 Feb 2020 at 15:08, Ken Goldman <kgo...@us...> wrote: > I don't know the answer, but I think I understand the issue at > a high level. > > You said that the TPM emulator is returning success, but the TSS > is not. Along with the 'authsess' hint, it appears that the TPM > returns success and a response HMAC, but the TSS fails when > verifying the response HMAC. > > There are two response HMACs, one for the sealed object and one for the > parent. Are you doing anything unusual with either session or password? > > Unless the TSS has some tracing capability, you'll have to set through > trousers in a debugger. Fortunately, the TPM side does extensive > tracing of the HMAC calculation, so you should not need a debugger in > that side. > > On 2/8/2020 7:30 AM, Sam Jenkins via TrouSerS-users wrote: > > Hello, after some further debugging, making use of a debug build of the > > library and GDB I've found that my failure is occurring when data unseal > > calls authsess_xsap_verify(xsap, &digest). > > which supposedly checks whether or not the session is authorised, but Im > > not actually sure what that means in this context, Im using the correct > > keys, so Im not sure what to do about not being in an "authorised > session" > > > > > > > _______________________________________________ > TrouSerS-users mailing list > Tro...@li... > https://lists.sourceforge.net/lists/listinfo/trousers-users > -- hello |
From: Ken G. <kgo...@us...> - 2020-02-10 15:08:30
|
I don't know the answer, but I think I understand the issue at a high level. You said that the TPM emulator is returning success, but the TSS is not. Along with the 'authsess' hint, it appears that the TPM returns success and a response HMAC, but the TSS fails when verifying the response HMAC. There are two response HMACs, one for the sealed object and one for the parent. Are you doing anything unusual with either session or password? Unless the TSS has some tracing capability, you'll have to set through trousers in a debugger. Fortunately, the TPM side does extensive tracing of the HMAC calculation, so you should not need a debugger in that side. On 2/8/2020 7:30 AM, Sam Jenkins via TrouSerS-users wrote: > Hello, after some further debugging, making use of a debug build of the > library and GDB I've found that my failure is occurring when data unseal > calls authsess_xsap_verify(xsap, &digest). > which supposedly checks whether or not the session is authorised, but Im > not actually sure what that means in this context, Im using the correct > keys, so Im not sure what to do about not being in an "authorised session" |
From: Sam J. <sam...@go...> - 2020-02-08 12:30:58
|
Hello, after some further debugging, making use of a debug build of the library and GDB I've found that my failure is occurring when data unseal calls authsess_xsap_verify(xsap, &digest). which supposedly checks whether or not the session is authorised, but Im not actually sure what that means in this context, Im using the correct keys, so Im not sure what to do about not being in an "authorised session" Thanks, Sam Jenkins On Tue, 4 Feb 2020 at 14:17, Kenneth Goldman <kgo...@us...> wrote: > Unfortunately, I know the TPM well (I wrote the simulator and > was the spec editor), but I don't know trousers. > > I think trousers has a verbose mode. Does its trace show anything? > > If no one on the mailing list can help, I think you're have > to run the TSS in a debugger. > > > From: Sam Jenkins <sam...@go...> > > To: Ken Goldman <kgo...@us...> > > Cc: tro...@li... > > Date: 02/04/2020 04:20 AM > > Subject: [EXTERNAL] Re: [TrouSerS-users] Unable to unseal data > > > > The return code is 1, i.e. not successful, but when I ran the > > emulator in debug mode to try and get more information, its saying > > unseal ran successfully, so honestly Im not sure where the failure > > is occurring. > > If you have any suggestions they'd be much appreciated. > > Thanks > > > > On Mon, 3 Feb 2020 at 13:54, Ken Goldman <kgo...@us...> wrote: > > Does the emulator show the unseal failing? I.e., is the TPM return code > > not success? If so, I can help. If not, you need a trousers expert. > > > > On 2/1/2020 12:57 PM, Sam Jenkins via TrouSerS-users wrote: > > > After some further debugging, without much to show for it, I've found > > > that I had an issue where the tpm emulator was complaining about > > > Tspi_LoadKeyByUUID, which appears to have been due to the key > requiring > > > authorisation, as such, GetKeyByUUID and LoadKey has to be used > instead, > > > while this has silenced the only error the tpm emulators is giving me, > > > it still leads to tspi_data_unseal producing the return code 1. Making > > > the matter more confusing is that, despite the key apparently not > > > loading properly, tspi_data_seal was and is still working fine. Any > > > support here would be greatly appreciated. > > > > > > > > > > _______________________________________________ > > TrouSerS-users mailing list > > Tro...@li... > > https://lists.sourceforge.net/lists/listinfo/trousers-users > > > > > > -- > > hello > -- hello |
From: Martin G. <omg...@gm...> - 2020-02-07 19:04:12
|
Hi all, Following my last thread, I'm investigating how to build a static libtspi for my app to link against, so that it can communicate with tcsd in order to query TPM info. I've been following the README, but I'm not seeing any specific instructions for building statically. Right now I'm running the following: CFLAGS="-L/usr/lib64 -L/opt/gnome/lib64" LDFLAGS="-L/usr/lib64 -L/opt/gnome/lib64" ./configure --enable-static=yes --enable-shared=no --with-openssl=/home/martin/openssl/install The --with-openssl path points to a static build of OpenSSL that my app links against. However, when doing this I get the following errors: libtool: compile: gcc -DPACKAGE_NAME=\"trousers\" -DPACKAGE_TARNAME=\"trousers\" -DPACKAGE_VERSION=\"0.3.9\" "-DPACKAGE_STRING=\"trousers 0.3.9\"" -DPACKAGE_BUGREPORT=\"tro...@li...\" -DPACKAGE_URL=\"\" -DPACKAGE=\"trousers\" -DVERSION=\"0.3.9\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_OPENSSL_BN_H=1 -DHAVE_OPENSSL_ENGINE_H=1 -DHAVE_PTHREAD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHTOLE_DEFINED=1 -DHAVE_DAEMON=1 -I. -DAPPID=\"TSPI\" -I../../src/include -L/usr/lib64 -L/opt/gnome/lib64 -DBI_OPENSSL -W -Wall -Werror -Wno-unused-parameter -Wsign-compare -I../include -DTCSD_DEFAULT_PORT=30003 -DTSS_VER_MAJOR=0 -DTSS_VER_MINOR=3 -DTSS_SPEC_MAJOR=1 -DTSS_SPEC_MINOR=2 -c crypto/openssl/hash.c -o libtrousers_la-hash.o crypto/openssl/rsa.c: In function ‘Trspi_RSA_Encrypt’: crypto/openssl/rsa.c:71:5: error: dereferencing pointer to incomplete type ‘RSA {aka struct rsa_st}’ rsa->n = BN_bin2bn(publicKey, keysize, rsa->n); ^~ Makefile:415: recipe for target 'libtrousers_la-rsa.lo' failed make[2]: *** [libtrousers_la-rsa.lo] Error 1 make[2]: *** Waiting for unfinished jobs.... crypto/openssl/symmetric.c: In function ‘Trspi_Encrypt_ECB’: crypto/openssl/symmetric.c:55:17: error: storage size of ‘ctx’ isn’t known EVP_CIPHER_CTX ctx; It seems like the build system isn't finding the libssl/libcrypto symbols. Am I doing something wrong here? |
From: David C. <dav...@gm...> - 2020-02-07 17:27:35
|
The tcsi is speced in the tch spec. On Fri, Feb 7, 2020, 8:50 AM Martin Galvan <omg...@gm...> wrote: > Got it, thanks. I think I'll look into (statically) linking against > libtspi though, if only to keep that option in mind. > > Thanks a lot for the responses. > > El vie., 7 feb. 2020 a las 12:44, Ken Goldman (<kgo...@us...>) > escribió: > > > > On 2/7/2020 9:42 AM, Martin Galvan wrote: > > > Hi Ken, thanks a lot for the response. > > > > > > El vie., 7 feb. 2020 a las 11:15, Ken Goldman (<kgo...@us...>) > escribió: > > >> In theory, you don't have to link to the TSS to connect to > > >> tcsd. However, I don't think the tcsd interface is documented, > > >> so it may be a lot of work. > > > > > > I was thinking of doing this, however what concerns me is how stable > > > this interface would be. If something changes, my app may break in > > > unexpected ways. > > > > My guess: > > > > In theory, it's undocumented and thus can change. > > > > In practice, trousers has been out for a long time. I suspect that > > code changes now are just bug fixes, not new features. So you > > can hope that the interface is stable. > > > > > > > > _______________________________________________ > > TrouSerS-users mailing list > > Tro...@li... > > https://lists.sourceforge.net/lists/listinfo/trousers-users > > > _______________________________________________ > TrouSerS-users mailing list > Tro...@li... > https://lists.sourceforge.net/lists/listinfo/trousers-users > |
From: Martin G. <omg...@gm...> - 2020-02-07 15:49:55
|
Got it, thanks. I think I'll look into (statically) linking against libtspi though, if only to keep that option in mind. Thanks a lot for the responses. El vie., 7 feb. 2020 a las 12:44, Ken Goldman (<kgo...@us...>) escribió: > > On 2/7/2020 9:42 AM, Martin Galvan wrote: > > Hi Ken, thanks a lot for the response. > > > > El vie., 7 feb. 2020 a las 11:15, Ken Goldman (<kgo...@us...>) escribió: > >> In theory, you don't have to link to the TSS to connect to > >> tcsd. However, I don't think the tcsd interface is documented, > >> so it may be a lot of work. > > > > I was thinking of doing this, however what concerns me is how stable > > this interface would be. If something changes, my app may break in > > unexpected ways. > > My guess: > > In theory, it's undocumented and thus can change. > > In practice, trousers has been out for a long time. I suspect that > code changes now are just bug fixes, not new features. So you > can hope that the interface is stable. > > > > _______________________________________________ > TrouSerS-users mailing list > Tro...@li... > https://lists.sourceforge.net/lists/listinfo/trousers-users |
From: Ken G. <kgo...@us...> - 2020-02-07 15:44:34
|
On 2/7/2020 9:42 AM, Martin Galvan wrote: > Hi Ken, thanks a lot for the response. > > El vie., 7 feb. 2020 a las 11:15, Ken Goldman (<kgo...@us...>) escribió: >> In theory, you don't have to link to the TSS to connect to >> tcsd. However, I don't think the tcsd interface is documented, >> so it may be a lot of work. > > I was thinking of doing this, however what concerns me is how stable > this interface would be. If something changes, my app may break in > unexpected ways. My guess: In theory, it's undocumented and thus can change. In practice, trousers has been out for a long time. I suspect that code changes now are just bug fixes, not new features. So you can hope that the interface is stable. |
From: Martin G. <omg...@gm...> - 2020-02-07 14:42:46
|
Hi Ken, thanks a lot for the response. El vie., 7 feb. 2020 a las 11:15, Ken Goldman (<kgo...@us...>) escribió: > In theory, you don't have to link to the TSS to connect to > tcsd. However, I don't think the tcsd interface is documented, > so it may be a lot of work. I was thinking of doing this, however what concerns me is how stable this interface would be. If something changes, my app may break in unexpected ways. > BTW, for TPM 2.0, the resource manager is built into the device > driver. There is no tcsd or other user space daemon. It's > a much cleaner design. That's great to know! Thanks. |
From: Ken G. <kgo...@us...> - 2020-02-07 14:15:02
|
On 2/6/2020 3:42 PM, Martin Galvan wrote: > Hi all, > > I'm working on an application that needs to retrieve some information > from a 1.2 TPM, such as its manufacturer info and values of its > Permanent flags. My application usually just opens the TPM driver and > talks directly to it; however, I saw that tcsd will open the driver > and make it return EBUSY whenever my app tries to open it. Looking at > man tcsd I saw the following: > > "tcsd is a user space daemon that should be (according to the TSS > spec) the only portal to the TPM device driver. At boot time, tcsd > should be started, it should open the TPM device driver and from that > point on, all requests to the TPM should go through the TSS stack." > > I understand that, in order to talk to tcsd, my app should be linked > against libtspi. This is undesirable for many reasons, so I'd like to > know whether there's another way for me to communicate with the TPM > when tcsd is running. tcsd locks the TPM device driver by design because it handles scheduling and resource management. If another process could, e.g., flush a key, applications would break. In theory, you don't have to link to the TSS to connect to tcsd. However, I don't think the tcsd interface is documented, so it may be a lot of work. BTW, for TPM 2.0, the resource manager is built into the device driver. There is no tcsd or other user space daemon. It's a much cleaner design. |