I am totally new and working on TPM 2.0 commands based on link below
https://manpages.debian.org/testing/tpm2-tools/index.html
I am trying to take ownership of TPM
in previous version I tried taking ownership it asks password for owner and SRK for TPM 2 its not asking
I have some questions on TPM
How to get EK and SRK using
command
How to take ownership
How can i load/retrieve the certificate/key in/from TPM.
Is there ant tool to interact with TPM as of now I am using tpm2-tools
I googled a lot for it but I am confused wether I am right or not.
Any help many thanks
First you would take ownership with tpm2_takeownership. This gives you the hierarchy passwords you will need later on.
Then you would create the endorsement key with tpm2_createek.
Then you would create the storage root key with tpm2_createprimary, under TPM_RH_OWNER. Then you would make the SRK persistent with tpm2_evictcontrol.
It is not clear what you mean by loading the certificate to the TPM... But if you mean signing a key certificate by a root CA and storing it in the TPM, then you would store it in NV RAM and make it persistent (again with tpm2_evictcontrol) at the appropriate index handle (for example, in accordance with the TCG guidance).
NOTE: tpm2_takeownership has been split into tpm2_clear and tpm2_changeauth.
Related
This is more a "concept" question than a real programing one. However, having to constraint to work on embedded systems have to be kept in mind.
Here is a little bit of context : I am working on a project that uses an stm32 prototyping board (STM32G431KB to be precise, bare-metal (so C / C++) ) and my goal is to safely store sensitive data in files so that only an authenticated person would be able to read them. I would like to avoid symmetric encryption as it is not as safe as asymmetric.
Files are stored on an SDCard. And the particularity is that I need to encrypt them "on the fly". I plan to acquire data approximately every second and add them to a file. Re-encrypting the whole file at each data save is not a solution as these ones may be large.
So, my question is : how could I achieve this?
I am completely new to this kind of concerns and would like to know if someone more experienced could share a few tips or things I could search. I assume that hybrid encryption could be the most suitable regarding my constraints, however, I am not sure this would be a correct way to use it :
Generate a pair of private/public key and store the private on the device
Using the public key to encrypt a symmetric key generated on a trusted host
Get this key on device startup and use it to encrypt the file using CBC encryption
What would be the flaws of such a setup?
PS : just to clarify, the device is not connected to internet. The only interactions possible with a host would be over serial communication or just reading/writing data to the sdcard
I'm not sure if this is normal behavior or not. Everytime I access the blockchain a new private/public key pair is created and saved in .hfc-key-store. Therefore this folder becomes huge, how do you handle that? Thanks
The Node SDK supports loading existing credentials. The likely cause of this is that you are actually enrolling each time rather than using existing credentials as much of the sample code actually does this for convenience.
I am trying to figure out a solution to a 'chicken and egg' issue which I have come across in a project I am working on for a new venture.
The systems in question are handing credit card data and as such the card numbers etc need to be stored encrypted in the database. In order to comply with PCI requirements we have the numbers encrypted with unique key pairs for each 'merchant', so if one merchant is compromised it shouldn't be possible to access another merchants card holder data.
This is fine when it comes to human interaction with the system, as the human can enter the passphrase to unlock the private key, and then decrypt the data, however when it comes to automated services which need to access the data (i.e. to process transactions at a later date) there is an issue with how best to provide the credentials to the service/daemon process.
A bit of background on the system:
card numbers are encrypted with asymmetric key pairs
the private key is passphrase protected
this passphrase is then encrypted with a 'master' key pair
the passphrase to unlock the master private key is then known by the operators granted permission (well, actually they a copy of it encrypted with their own key pair which they only know the passphrase to).
the daemon process will be run as its own user and group on a linux system.
For the daemon to be able to decrypt the data I was considering the following:
Setup a passphrase file similar to how .pgpass works
Store the file in the home directory for the daemon user
Set the permissions to 0600 for the file
Setup a file integrity monitoring system such as Tripwire to notify a security group (or similar) of any changes to the file or permissions.
Disable login for the daemon user, as it is used only for the process.
Given the above, I am wondering if this is sufficient. Obviously the weakness is with the system administrators - there are few of these (i.e. 2) trusted on the secure systems - given they can elevate their permissions (i.e. to root) and then change ownership on the files or the permissions to be able to read the passphrase - however once again this is likely something which can be mitigated with monitoring of checksum changes for files, FIM checksums etc.
So am I going about this the wrong way or are there other suggestions on how to handle this?
Not sure how much help this will be as given your aim is compliance with PCI-DSS the person you need to convince is your QSA.
Most QSA companies are happy to work in a consultative capacity and help you find a suitable solution rather than working purely in an assessment capacity so get them involved early and work with them to get a solution they are happy to sign off as compliant.
It may be worth getting them to document why it is sufficient as well so that if you change QSA in the future you can take the reasoning with you in case the subject comes up again.
One thing they are likely to mention based on the above solution is split knowledge for key management. It sounds like a single administrator has all the knowledge needed to access keys where PCI (3.6.6) requires split knowledge and dual control for manual clear-text key-management procedures.
I am using Bouncy Castle to generate a public/private keypair and using it for encryption tasks.
What would be the best way to store the keypair securely?
I have been unable to find a way to store on the devices keystore. Storing on a txt file wont work because it is as insecure as it gets. I could store it in RMS but then how does one secure this from a person with enough motivation to snoop?
Data store Update:
Problem with RMS is that if the application is saved in the mem card then the datastore is easily accessible to anyone.
As you're already using Bouncy Castle, then just implement a simple PBE (password based encryption) scheme to allow the records stored to be encrypted. For an example on how to do this have a look at the simple application I wrote many years ago.
http://www.eaves.org/jon/j2me/pocket.shtml
If you look at the .record package, you can see what I've done to encrypt and store individual records.
The "downside" to this approach is that you need to get the user to choose a "passphrase" and use that as part of the PBE. I'm not aware of any other approach to do what you want to do, and maintain security over the information stored. Any attempt to "hide" the key is futile, and insecure.
see my answer here, its secure to save in record store
How to sort recordstore records based on a certain field in it?
every application have its own record store and removed on application uninstall
I'm trying to figure out how best to set up Authenticode signing at my workplace. The security implications are stressing me out.
My initial thought is that the person who controls the key should install it to the build server and secure it so that only the build account can access it.
This seems reasonably secure, but it actually isn't. Yes, you can't steal the cert at this point, but if you can create a build you can get the build account to sign any binary.
Does anyone who is familiar with the process give me some pointers?
Indeed, if the key is available for use in build account, it's available for admin's account and it can be used to sign other file. Whatever you give to others' posession is not yours anymore. If you can't secure the server from other people access, then you don't control the server fully, and this leaves a chance for misuse. Frankly speaking, I can't imagine a single way (other than move signing to some other trusted system) to protect the key from misuse. Even when the key can't be extracted or copied (say it's put to cryptotoken), it still can be used in some way.