I'm new in node.js and I need to implement digital signatures.The Scenario is that, a user "A" will send some data by signing it with its private key (Stored on local machine) on to the server. So any other user "B" can verify it by decrypting the data with public key (Stored in DB on server) of "A".
Now following are my questions.
How to generate public private keys?
How to store private key on local machine?
How to sign data using private key and how to verify it using public key?
I found the below flow diagram on google. You can use this to get a grasp of he functionality. You can use this library to implement your signatures. Not sure if this solves your problem or not, but I hope it will help you in getting some clarity.
Related
HL Fabric supports a state store and a crypto store as can be seen here for example. But what is the difference between these two stores? It looks like both will store some kind of secrets but what store is used for what?
Some links I found but none of them address the question:
https://jira.hyperledger.org/browse/FABN-643
https://fabric-sdk-node.github.io/Client.html says:
The client also supports persistence via a stateStore. A state store
is a simple storage plugin that implements
the module:api.KeyValueStore interface, which helps the SDK save
critical information to be used across server restarts/crashes. Out of
the box, the SDK saves the signing identities (instances of
the User class) in the state store.
So we think we have some idea of what the state store is used for. But what is cryptoStore used for then?
cryptoStore stores the private keys. State store stores the certificates obtained from fabric-ca
The crypto store stores the public and private keys.
State store stores the public X509 certificate plus some metadata and a pointer to the keys in the crypto store. In image below, the signingIdentity is the pointer.
I am working on a project where I need the functionality of user registration and user login. I need some suggestion. What would be the better way of achieving this task?
A.) Old school email & password OR B.) By using public & private keys?
What I understand from option B is that we need to enroll a user from CA from Fabric-SDK. Once enrolment of user is done, we can generate a unique password-phrase like the same is happening in Meta-Mask. We can store that user info along with its username (the default username in fabric is user1, user2) with password-phrase.During user login, it will ask for user's private key or the unique password-phrase generated for its account. The certificates will be stored in hfc-keystore (the default dir used in Hyperledger fabric). Whenever a transaction is executed by that user say user akshay.sood, we will set the context of that user to fabric-client (Please correct if I am wrong in this case).
Here, My questions/queries are:
1.) What do you prefer (email/password or private/public keys and why?).
2.) If you prefer 2nd mechanism then how will you protect user keys and certificates stored in hfc-keystore dir. I mean it can be hacked or data can be stolen by hacker.
3.) How to recover user private/public key and certificate if it is deleted mistakenly from hfc-dir.
4.) Would you prefer using password-phrase? if no, what do you prefer?
Edits are welcome.
Please let me know if you have any suggestion/improvements
Your question is a choice of your preference, convenience & business needs. You can use either or both approaches in combination. Asking the user to keep or manage his private keys calls for a managed wallet. However, IMHO, if you are concerned about leakage or loss of private keys then you would need a Hardware Security Module that is specifically designed for this purpose.
P.S. Fabric & its examples store the keys in hfc folder for simplicity, although not recommended in real cases.
I have a requirement that, any number of customers can log into one company site and they will upload some documents for identity proofs, And the company can verify the documents by opening and accepts if documents are fine otherwise reject of documents are fake.
When the user login again into the site, he has to see whether the uploaded docs are approved/rejected by company.
How do we achieve this requirement in hyperledger fabric 1.0 and
How the user details are restricted from other users even though we are using distributed ledger?
Can anyone suggest me the solutions for this?
I guess one approach would be that the company has a chaincode that has access to (either hardcoded or by some other means) a public key that its corresponding private key is unavailable to the channel in which the users are using.
The user submits in a transaction:
Its document
An AES key - generated by the user and passed via the transient map.
The chaincode, then:
Encrypts the document with the AES key
Stores the encrypted (with AES) document in the chaincode
Stores the encrypted AES key (with the company's public key)
Now, the company has the private key - so it can decrypt the public key of each user and then decrypt the document.
That's a high level solution. If you have questions on the details feel free to add a question in a comment, or ping me in chat.hyperledger.org (name is same as username here)
So far most of our clients (online retailers and banks) have been reticent of placing any parts of theirs applications to a public cloud, although this could be a very cost effective manner to deal with temporary demand upsurge (end of month, holidays etc.)
We could place middle tier on a cloud so that no information is persisted in the cloud, or so that only non-sensitive data is stored there.
What are the best practices in this case?
Are there any regulations that I should be aware?
What are the biggest threats?
The best solution is to use cryptography.
You have the choice of public key cryptography: encrypt your data with a public key, put it "on ze cloud", then when you retrieve it, decrypt with your private key. Even better, if the data only transits through you, you can only have the public key and only your client has the private key.
Or symmetric cryptography, in which case you need the key, which will help encrypt and decrypt.
Symmetric cryptography algorithms are much faster, but if the scenario I mentioned above applies (ie, the client can have the private key), definitely go for it: you won't even be able to read the data without the client's consent.
Here is the model we are using to store the CC details how secure does this look?
All our information is encrypted using public key encryption and the keypair is user dependent (its generated on the server and the private key is symmetric encrypted using the users password which is also Hashed on the database) So basically on first run the user sends in his password via a SSL connection and the password is used with the addition of salt to generate an MD5 hash, also the password is used to encrypt the private key and the private key is stored on the server. When the user wants to make a payment, he sends his password. The password decrypts the private key, and the private key decrypts the CC details and the CC details are charged.
If the user's password is secure enough to protect the private key, why not skip the private key and use password (via a suitable key derivation algorithm) to encrypt the credit card number? Unnecessary complications definitely do not improve security.
This scheme doesn't use the public key for anything, indicating that an asymmetric algorithm is out of place here.
This ties the credit card's security to the strength of the user's password, which varies from user to user and is generally weak. It's better to creating your own symmetric encryption key, keeping that safe, and then doing a bunch of complicated stuff that experts invented, involving initialisms like CBC, CTR, and IV.
I am not sure if you store card number and private key files together. It seems like by just using user password to encrypt private key file you are opening the door for dictionary style attack if the encrypted private key files are available.
Not sure why you want to use public key cryptography which can be pretty slow. Also the model of 1 key pair per user may not scale (how many files, can you generate parameters for public key operations). Note that you may have abusive behavior - people checking to see if their list of stolen cards are good.
You could still prevent any use of card number when user is not present by adding your own master secret and deriving key schedule from combination. In general most merchants can't follow this strict requirement as there is a valid need to use card number when user is not present.
If you just want user specific keys (and you must use a different IV every time), then you can go the openssl EVP_BytesToKey route and pass a different salt each time with the master secret from which the encryption key and iv will be derived (and they will be different for each user).
Finally use of payment instrument is protected by just user password as described. Some users choose weak passwords. So you may want to use additional proofing to ensure card belongs to user - some of this is for your own good as you can fight friendly fraud chargebacks and keep your real fraud chargebacks low.
I agree with erickson that if the public key isn't used there is no point in doing asymmetric crypto.
As always the problem here is a key-management problem. The insecurity arises from not knowing how to safely hide the key that decrypts the data.
Im not sure if it is possible, but if you can afford it buy a hardware security module and let you HSM manage the keys, or encrypt all customer (private) keys with the HSM master key.
If you cannot, you should find a suitable place to store your "master" key, a possible example is the windows store (if that is a possibility). However, I most admit that i dont really know how secure the windows store is.
You may want to take a look the Payment Card Industryies "Payment Application DSS"" https://www.pcisecuritystandards.org/security_standards/pa_dss.shtml
It may help make some decisions for you.