Activity for Nigel Hathaway
-
Nigel Hathaway modified a comment on ticket #29
Actually, instead of defining WIN32_LEAN_AND_MEAN, define NOCRYPT instead. In this way, you don't need to include winsock.h. See https://stackoverflow.com/questions/11040133/what-does-defining-win32-lean-and-mean-exclude-exactly
-
Actually, instread of defining WIN32_LEAN_AND_MEAN, define NOCRYPT instead. In this way, you don't need to include winsock.h. See https://stackoverflow.com/questions/11040133/what-does-defining-win32-lean-and-mean-exclude-exactly
-
It looks like we need to add the line: #include <winsock.h> after #include <windows.h> at line 52 of tssproperties.h
-
Thanks for this. Defining WIN32_LEAN_AND_MEAN solves this. However, new errors appear. In tssproperties.h, line 66 typedef SOCKET TSS_SOCKET_FD; fails as SOCKET is undefined. In tssproperties.c, TSS_CONTEXT claims to be undefined. Simarly in tsstransmit.c
-
Old eay libs referenced in Visual Studio project
-
Old eay libs referenced in Visual Studio project
-
Yes, I believe it does, and I think my question has been answered. I'll try it out and see...
-
Hmm.... I'm still not completely clear on how this is done and if it is possible. Firstly, the backup is a bit of a red herring. Let's leave that out. My (simplified down) scenario is this: I have a master key machine on which I create lots of keys to be re-assigned later. At a later date I decide I want to send one of the keys to a "user" machine, and we assume that the user has root access to that machine. What we need to be able to do is ensure that, having duplicated the key to that user machine,...
-
The problem is the Linux device driver not the TSS library. The Linux driver (in all kernels known to me at the time of writing) works with physical TPMs - that is with TPMs that are a device separate to the CPU chip, e.g. soldered onto the motherboard. The problem comes with Intel's firmware TPM implementation, which does not use a separate physical TPM, but is a software implemention in a part of the CPU chip, isolated from what the OS can see, except via its "BIOS" interface. The problem seems...
-
I have been doing some of my own research into this, any what I have found is a bit confusing. Firstly in the book "A Practical Guide to TPM 2.0" which has a familiar name in the authorship. ;-) Looking at the section 'Duplication' on p253, it mentions TPM2_DuplicationSelect and TPM2_DuplicateSelect. There is no mention of these in the spec, but the spec does mention TPM2_PolicyDuplicationSelect, so I assume this is a typo. However, it doesn't say how this is used in the context that I am looking...
-
To answer my own original question, the answer is no. Or at least not with any of the kernels on any of the distributions I have tried, which includes Ubuntu 18.04. The reason is thrown about here: https://sourceforge.net/p/tpmdd/mailman/tpmdd-devel/thread/CB2C93A3-6F29-4511-8FDD-B29D98FA235C@gmail.com/ A patch people seem to think fixes the problem is here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=422eac3f7deae34dbaffd08e03e27f37a5394a56 I don't know if this...
-
Agreed. In the end it was found to be due to the way different versions of openssl generate AES keys from passwords. We were using a TPM-RSA-encrypted packet to store the AES key password used in transferring data, which generated different AES keys at the sender and the receiver (which ran different openssl versions). (Generating the AES key did not involve any TPM operations). So this issue had nothing to do with the TPM. I am putting this here to warn people not to generate AES keys using passwords...
-
Debian Stretch says it's a 4.9 kernel
-
Hmm... strange. I did a simple test based off your testrsa.sh, and the simulated and real TPMs did inter-operate. For a given identical imported openssl RSA key, both sides produced the same enc.bin file. There must be something strange going on in the wider context of our application.
-
The Intel NUC in question uses the Infineon SLB9665TT2.0 as its TPM. Is this one of the parts you have tried? (See https://www.intel.com/content/dam/support/us/en/documents/boardsandkits/NUC5i3MYBE_TechProdSpec.pdf page 44) I will do some further tests and get back to you.
-
It sounds like we'll just have to take the plunge and buy one to try it out. Regarding /dev/tpmrm0, I don't see this. I just see /dev/tpm0. We are using Debian Stretch (i.e. current stable). Would this be because this kernel feature is too new to be included in that Debian version?
-
Do we know if the TSS library works with Intel fTPM running under Linux (in our case, 64-bit Debian Stretch)? We are looking at using an Intel NUC5i3RYH or similar - primarily because we think it can't possibly be as slow as a discrete TPM, which we find can take up to a minute-an-a-half to do createprimary.
-
One of the things I have found is that if I encrypt something on a real TPM and try do decrypt it on the TPM simulator, it doen't work - and vice versa in all combinations. I'm talking RSA here. I find that all instances of the real TPM will talk to one another, and all instance of the simulated TPM will talk to one another. Is this deliberate, or is something strange doing on? The real TPM in question is on an Intel NUC5i3MYHE.
-
One of the tings I have found is that if I encrypt something on a real TPM and try do decrypt it on the TPM simulator, it doen't work - and vice versa in all combinations. I'm talking RSA here. I find that all instances of the real TPM will talk to one another, and all instance of the simulated TPM will talk to one another. Is this deliberate, or is something strange doing on? The real TPM in question is on an Intel NUC5i3MYHE.
-
It's useful to be able to keep a copy of keys in multiple locations for backup purposes, and hence those keys have to be created migrateable. However, you then want to deploy thoses keys to their final useage locations and, ideally (in some circumatances) you want to be able to do this in such a way that that those keys cannot be further migtated (copied) from those final useage locations. Can this be done with TPM2.0? I looked and couldn't find anything on the subject.
-
I'm actually building against 1.01f (in Ubuntu 14.04) and (what recently was) the latest stable from the openssl web site. Unfortunately, ECDSA_SIG_set0 is not available in the old version but you have to use it in the new. Somewhere in between it is deprecated then removed (which to me is rather a short timescale to do that in). However, OpenSSL don't officially support the older version (their oldest is 1.02) whereas the Linux distros do. So you may want to put conditional compilation around i...
-
Compile failure
-
Build fails under certain compilers
-
Here is my version of the patch, if anyone is interested.
-
Openssl version build issue
1