In a Mac application, I have a requirement to store the private key sent from the server for logged in user in a secure way and retrieve it back whenever needed programmatically. I know that keychain is the best place to store the private key. Is there any sample code available to achieve this?
I am able to add the private key to the keychain using "SecKeychainItemImport" method of "Security.framework" but having issues retrieving back the private key from the keychain. I have tried using "SecKeychainItemCopyAttributesAndData" and "SecKeychainItemCopyContent" methods for getting private key back from the keychain. But no luck so far.
I have also read in blogs mentioning private key storage inside ".ssh" hidden folder. But I feel that storing the private key inside the keychain provides one more level of security so that someone else can not have an easy access to the private key.
One purpose of the Keychain is to keep private keys protected by not exposing their data to the application. To prevent accidentally exposing a private key, these items are flagged CSSM_KEYATTR_EXTRACTABLE | CSSM_KEYATTR_SENSITIVE by default; i.e., it is only possible to get their data using SecKeychainItemExport, and only in a passphrase-protected format.
There are APIs in the Security framework that encrypt/decrypt/sign/verify etc. data using a supplied key item without ever putting the raw key data in the application's address space. (These operations are normally done by a separate, privileged process.)
If for some reason you do need access to the private key's raw bits, you need to prepare for this at the time you import the private key to the keychain. You need to set keyAttributes to CSSM_KEYATTR_EXTRACTABLE (i.e., without the sensitive bit) in the keyParams parameter of SecKeychainItemImport.
Yes, the Keychain is what you'd use here. You want to read the documentation first, then look at Apple's sample code.
http://developer.apple.com/library/mac/#documentation/Security/Conceptual/keychainServConcepts/01introduction/introduction.html
http://developer.apple.com/library/ios/#samplecode/GenericKeychain/Introduction/Intro.html
Related
I am trying to implement direct Integraion of Google pay into our website and in docs, it is mentioned that merchants have to anually rotate the keys in case of direct integration and old private key should be supported upto 8 days after removing of public key. My question is can I always use old private key during decryption even after rotation of public key? I can update the new public key anually but I would like to use the same old private key. Will it work forever during decryption or is there any time period which it gets invalidated?
I want to sell some of my collectable items that I have been collecting over the years. But I don't want to just sell it, I want to add a QR code to the item (back of the painting, on the deck of cards etc.) and have that link to a website that can verify the item is the real thing.
I was thinking of using pgp-keys (public/private) to verify the item.
Is there already a way to do this or would I have to write something to decrypt the private key for validation? What language would be able to do this, can I do it in python?
This depends on what you are actually seeking to do.
You could embed a message that you sign with your private key, which can then be verified to be authentic with your public key.
If you want the message to be encrypted, you will need to pass a private key to the buyer and encrypt the message with the corresponding public key.
Generally, you don't need the private key unless you are doing encryption or signing. There are libraries for PGP in essentially all programming languages, python has python-gnupg for this.
I'm working on a distributed application, and we need a way to authorize clients. Every client has a PGP keypair associated with them, and we require them to enter their private key (which is not stored) through which their pubkey is derived and used to identify clients and modify their fields on the distributed database.
Now, considering user experience, entering a private key on a website whenever you need to do something is troublesome. But we also cannot maintain a central database for username/password based authentication as that creates a single failure point (not what the distributed application is meant to do)
I am hoping there is some way to get an easier to remember human readable descriptor of the private key which can be used to authenticate if something like that exists. Any other ideas are appreciated too.
I'll throw a bunch of ideas to clarify the question:
Are you certain that PGP is suited for your needs?
I feel like you should provide some more details to be sure:
- How are the private and public keys used exactly? I understand the following : user inputs its private key, information is decrypted and modified, public key is deduced from private and used to encrypt the updated information.
- How is this different from using a regular password and being able to authenticate the user and encrypt data?
- You seems to send private keys on the network, and they should remain private.
How you could use a regular password:
User has a password, your application uses a function (e.g sha256, KDF,...) to make it usable by classical encryption algorithms (e.g AES). With the same (not stored) key, you can then encrypt and decrypt datas. You just have to make sure that decryption is valid, by adding a known value at the beginning of the data (e.g a part of the key).
Quick example:
password: "WeakPassword"
key: sha256("WeakPassword"+"MySalt") = 493e3ae...b2eec8ef
Decrypt(data,key)
clearData = "493e3ae{123;456}" //valid, because you can check the beginning
Encrypt(clearData,key)
Advantages: usable passwords, faster symmetric encryption
Use a QR code
If you stick to PGP and have a camera available it is pretty handy.
You could also use hexadecimal, base64, ... but for a 2048 bits RSA key, that still gets you hundreds of characters.
I have seen that in the released projects (like Supply Chain) an off-chain database is used to save the user's information and state data. Is it possible to avoid using this database to save user information or is an implicit pattern of Sawtooth applications?
Private keys must be stored securely. At a minimum that means making the private key file unreadable to everyone but the owner (uw+o or 0600 permission). It is also a good idea to restrict access to the machine storing the private keys, if possible.
Better yet, use a software or hardware keystore (such as a hardware HSM).
Sawtooth does not store private keys in the global state or any database.
Public keys, which are not used for signing (just verification) are present in transactions and the blockchain.
I'm developing a small app that will help users easily get information from their isp provider, by scrapping their isp account page. For that to be possible I need their username and password store in my db. To keep their password safe I will use an openssl public key to encode it in my db and a private key to decode it before my scraper logs in to their account page.
I'm wondering where to put my private key so the passwords are safe even if someone take controller of my web server? Because It would be totally inappropriate to just leave the private key on the web server...
tks
If someone takes total control of your server and is interested in those passwords, he will succeed. Always take this into consideration and make plans on what to do in this case.
Now to make it as hard as possible and improbable to achieve this, I suggest to store the key (or better, the passwords) in some kind of memory table: like a Ramdisk, a script that will give out only one password per minute and delete itself if called more than that etc.
I don't see any positive effect of using public key encryption here, the key to decrypt must be stored on the server no matter what you use. You may look for Howtos that descripe the problem of https-certificates, they should be protected by passphrases and must be read on server start - the problem is related.
Probably a good solution would be to log into the server, store the passwordfile in a ramdisk and log out. Repeat on Server reboot, crash or password change.