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)
Related
I understand that Hyperledger stores private key of users in a directory called keystore. i don't want my network to store it rather user should upload this file before any transaction.
How to do it.
I don't have a full code to provide to you and I don't have time to write it. However, here is a flow you can follow:
FRONT END: Allow user to upload files (Example (assuming you are building a web application): http://reusableforms.com/d/o3/html5-contact-form-with-file-upload)
BACK END: Retrieve the file from the request.
BACK END: Create the user context from these files
BACK END: Build/send transaction
FABRIC: Process transaction
BACK END: If transaction is VALID, delete all the information about the user (private key in particular)
BACK END: Send response back to FRONT END
I do not know what is your scenario, but:
I think having the user manage its own keys is a risk, as he can lose it or someone may "hack" the user device to get it.
Having private keys moving on the network may be a security issue, has someone may be able to intercept it.
But as I said, I don't know your scenario. If you are in a closed network then transfering PK might not be a problem. If your client application manages the keys for the user, it may be ok too, but what if the user deletes it by mistake? Or what if the device is broken?
I think there's a misunderstanding of what the keystore folder accomplishes and what you want to accomplish here.
In the context of an MSP, the keystore folder does store private keys. It stores the private keys of the identities represented by the MSP. However, this is highly unique to the node that the MSP is running on.
On a peer, the keystore would store the certificate for the peer and the key for the peer identity. It would not store the keys for any other identity, as that node is not meant to act as that identity (remember that ownership of private = able to act as that identity). It would also store the certificates (not private keys) of the identities meant to act as administrators of that peer.
What exactly are you trying to do by allowing users to upload the private key? If you are trying to allow users to identify themselves to the network, providing their key is not the solution. If it's something else, try and edit your post to explain your use case more clearly so we can help.
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.
We want to migrate HSM keys from Thales paysheild 9000 to Azure Key vault. We would like to know if this migration is supported and if supported, what’s the migration approach and use cases where customers have already migrated to Azure. We have gone through the article https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/key-vault/key-vault-hsm-protected-keys.md, it talks about Thales nShield family but we are using https://www.thalesesecurity.com/products/payment-hsms/payshield-9000
Thanks in advance.
Excellent question, as Dan suggests you should contact Microsoft for clarification, but unfortunately I don't think it's possible.
Recapping, as I'm sure you are aware the purpose of HSM's is so that the keys are not exportable.
Microsoft (and I assume Thales) supports key backup: https://learn.microsoft.com/en-us/rest/api/keyvault/backupkey but it can only be restored to the same geographical area.
In the article you supplied it mentions "Key Exchange Key" in each geographical area, which I assume will mean that Microsoft will be using a different key to that of another install of an HSM.
Having said this I'm not a general HSM expert, these are just links I have come across over time using KeyVault.
Please do contact Microsoft as I would to be interested if this is possible, please post an answer once you have heard back or a Microsoft employee can perhaps answer directly.
On the Thales literature it states:
"With nShield BYOK for Microsoft Azure, your on-premises
nShield HSM generates, stores, wraps, and exports keys to the
Microsoft Azure Key Vault on your behalf"
http://go.thalesesecurity.com/rs/480-LWA-970/images/Thales-e-Security-Microsoft-Azure-UK-sb.pdf
Interestingly it says generates / stores which suggests a pre-created key could be migrated. However on the contray I'm guessing the export must happen using the "Key Exchange Key" and stored in both on-prem and exported for Azure at the same time, not on-prem first, in the BYOK process.
This blog post has keyvault team's contact details if it helps: https://blog.romyn.ca/key-management-in-azure/
The migration of important keys, that are encrypted under current LMK on your Thales payshield on premises, is very straightforward process:
1- Use console command GC to generate new ZMK in a clear format component, this will be done by using key type to be 000 which is ZMK key type, and also to choose clear format components option use letter 'x' in GC command steps.
2-Repeat the GC command above 3 times to generate 3 different plaintext format components of the new ZMK.
3-Now, at your payshield 9000 HSM, use the console command FK which means Form Key from components, the result is the new ZMK encrypted under old LMK.
4-Use the command KE ,which means export key, to export the important data encryption keys (DEK), such as ZPK for example, which is encrypted under old LMK to be encrypted under the new ZMK. Note: in KE command here use key type to be 001 which is ZPK key type.
5- Now you need to manually distribute the same new ZMK to the other party that you are going to migrate to.
6- You can do this manual distribution to such an important key (new ZMK) by sending the 3 different plaintext format components, which you have generated earlier in step number 2, to three different security officers at your corporate, and for security reasons, no one can have the 3 components all together.
7- On the other entity that you wanted to migrate your keys to, which is Microsoft Azure Key Vault cloud service, Azure is offering securing your keys in a hardware HSM environmental of nShield type, which is general purpose HSM and it is not specific in payment transactions like Thales payshield HSM.
8 - Refer to Microsoft Azure key vault documents, to know how to form the new ZMK of the 3 different plaintext format components that you have generated before, and refer to nShield manuals also to check the command which is responsible for importing keys.
9- Now, your important keys such as ZPK which was exported under new ZMK, are now imported under the same ZMK, and finally stored encrypted under the new LMK of your nShield provided cloud service.
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.
I'm developing custom client/server application that requires client to log in with their username and password. The user accounts are not related to Windows/AD accounts in any way. After login, client application will request other services from server system.
My question is what is the best way to implement this? What kind of architecture would fit best here? I guess some kind of ticket/token authentication system needs to be implemented???
Thanks
You may in fact want to implement a system which passes "tickets" along between the different parts (login server, client, app server). This ticket will contain basic information such as the user ID (the username, the row id, etc). This ticket will either be encrypted with a secret key that the authorized servers share, or will be stamped with a hash of the ticket contents salted with a secret key that the servers share. The first way makes it possible for only the authorized servers to create and read the ticket, and the second way makes it possible for the authorized servers to verify that only the authorized servers could have created the ticket but permits anyone to read the ticket. All app servers will check the ticket (by attempting to decrypt it or by verifying that the hash matches) before proceeding with any actions that should be protected. If this is a web app, then cookies are a good place to store the ticket.
You haven't said much about your architecture, other than it is Client/Server, so I am assuming you're using some sort of forms designer like Windows Forms in VS. In these cases I have always used some form of database table authentication, as it is easy, simple to setup, and reasonably secure. You can even set up groups and roles this way, without much fuss.
Table: Users
Fields: UserID PK
Login Text
Password Text
...
Table: Roles
Fields: RoleID PK
Role Text
...
Table: UserRoles
Fields: UserID FK
RoleID FK