I am trying to make following function with customized tokens. The goal is to mint tokens including metadata which is only exposed to the owner of token. This means that no one is permitted to read the metadata other than the owner. Is it possible to create such tokens?
Thank you.
You can implement that with Attribute Based Access Control with the help of Hyperledger Fabric CA, Chaincode's client identity library and some programming related key management techniques.
In Chaincode Side:
To store metadata, the chaincode will get the owner/user certificate with the help of client identity library and by parsing that certificate, chaincode will get certificate user's/owner's public key and hold the public key with a variable named as "variablePublicKey" and after that will store it's metadata with key "variablePublicKey.metadata".
To read the metadata, the chaincode will get the owner/user certificate with the help of client identity library and by parsing that certificate, chaincode will get certificate user's/owner's public key and hold the public key with a variable named as "variablePublicKey" and after that will get it's metadata with key "variablePublicKey.metadata".
To ensure security with this system, your chaincode must need to add some substring with each of user Input key. For example if user want to invoke or to query a car type asset, the chaincode will always add a substring with that user input, like user input key is "xyz" so the chaincode will add a substring with that like "xyz.car" and store/update value against the "xyz.car" key. To query a car, if the user give the input as "xyz", the chaincode will add a substring with that like "xyz.car" and query value against the "xyz.car" key
Related
I'm trying to revoke user by JAVA SDK
String crl = caClient.revoke(revoker, userToRevoke, "removefromcrl", true);
After executed the above line userToRevoke can still query and invoke normally. Why is it like that?
and what should I do next with this crl string?
Your nodes must update periodically the crls folder under their MSP folder. Otherwise, revoked certificates cannot be detected by the MSP.
https://hyperledger-fabric.readthedocs.io/en/latest/msp.html#msp-setup-on-the-peer-orderer-side
https://hyperledger-fabric-ca.readthedocs.io/en/latest/users-guide.html#generating-a-crl-certificate-revocation-list
And they should also be updated in the channel configuration, which is even more tedious.
I want to know the ability to perform the signature on a data record ( Workflow item for example) using certificates Stored in Active directory.
I guess the signing operation will be : get the certificate of a user from active directory and generate a signature to sign the Data with it. ==> "how to get a certificate of a certain user?!"
and I guess the verifying operation will be : compare the public key stored in the signature , with all public keys of certificates in active directory , till finding the matching one , to guarantee it is a verified signature
Is that true please ? do i miss the implementation of CRL check ? and trusting certificate in windows Trust Store? where to save public Keys?
How do I verify a user's extended public key file's integrity (when downloading through a connection that lacks confidentiality and authentication) when I have their previous (now expired) public key in my keyring? Is their expired key sufficient information to verify the extended key? Consider the below scenario:
I have Bob's trusted public key in my keyring.
Bob's key expired yesterday, so he extended his keypair and uploaded a new ascii-armoured public key to his website.
I downloaded Bob's new public key file over http, and I want to verify it.
Is the new public key file signed with his old key in a verifiable way? How would I verify the integrity of the new key file utilizing his existing (expired) key in my keyring?
For a general scenario with a new key pair: If either the key itself is signed by his old key (this is the usual way to do such key changes) and/or the key file you downloaded is signed by his old key, you can verify and validate the signature anyway: all that happens is GnuPG indicating that the key already expired.
But you wrote
Bob's key expired yesterday, so he extended his keypair and uploaded a new ascii-armoured public key to his website
Extending the key's validity does not produce a different key. They key is identified by the tuple of public key and creation timestamp, which is hashed together to the fingerprint of the key. Short and long key IDs are derived from that. If all he did is indeed extend the validity of the key, simply import the key. The signature and trust you issued on that key are still valid.
If you wish you can compare at least the long key ID before importing, run
gpg --keyid-format 0xlong [key-file]
and compare with the key already in your key chain.
Anyway: don't simply trust keys in your key chain, but use signatures and trust instead. Lots of mail clients automatically fetch keys to verify signatures, you might have fetched some (unvalidated) keys for reading signatures issued on other keys, ...
As Identity Provider we send a SAML assertion request to Service Provider and then they validate our signature in assertion using our certificate. SAML assertion contains an optional field called X509Certificate which is certificate of assertion issuer. (our certificate). My question is that from a security perspective is it better Service Provider use this field in each assertion for validating signature or use an external certificate file.
It's a very bad idea for them to only trust the public key value that is included in a signed message. Who's to say that someone couldn't just forge your EntityID and send them random SAMLResponses with some user data? The signature of the message would be valid, and they are using the key included in the message to validate the signature, right?
The benefits of offline key exchange are well known: Your SP has securely stored your public key and will always use to it validate the signature of your messages unless you instruct them otherwise (key rollover/update). If you include your certificate in the message, the SP will compare the two certificates first to ensure they match and then they should use the copy they have stored previously (assuming they match). Otherwise the message is rejected.
However, if you want an SP to trust the public key you include in your messages, the SP must be able to ensure that it is YOUR certificate that is being used. There are some smart folks at Ping Identity who have thought about this SP DSig Validation Use Case -- you can find a description of how they do this in their "Anchored Certificate" model for DSig Validation.
https://documentation.pingidentity.com/pingfederate/pf80/index.shtml#concept_digitalSigningPolicyCoordination.html
I don't really get the 11/19 answer. If you send your BinarySecurityToken (BST) in the Assertion for signature validation, and the receiver has an entry in his trust store with this public certificate, you should be good. In order for this to work:
1) The receiver must require that the assertion is signed
2) The receiver must check the signature verifying certificate in the assertion against a trust store.
3) DO NOT just trust the dn/issuer of the signer instead of using a trust store; that can be faked in a signing certificate.
If these things are followed, you have verified that the message is signed by the holder of the private key and that the assertion has not changed in flight. You then trust that holder, therefore you can proceed.
If the receiver doesn't require that an assertion is signed, anyone can send anything to the receiver.
If the receiver doesn't check a trust store for the verifying certificate, anyone can send a signed anything to the receiver.
The advantage of sending the BST in the message is that when your IdP certificate expires and you have to get a new one, the client only has to add your new certificate to his trust store instead of changing the configuration of his application.
I need to set up a two-step authentication chain with OpenAM. In the first step, the module requests a user certificate (which has to have been previously linked with an userID) and sends it to an external web service that will validate it and return the userID, which becomes the name of the Principal:
public Principal getPrincipal()
{
return new DataStorePrincipal(userID);
}
On the second step, the module asks the user to type in his userID and password. How do I make sure that the userID typed is the same as the one from step 1?
The modules are chained like this:
Certificate - REQUISITE
ID/Password - REQUIRED
The first module could save the 'userId' in the shared-state map, the 2nd module can read it from the shared-state map. You may look at existing auth-modules source as they provide support for 'shared-state'
You may also look at 'http://docs.forgerock.org/en/openam/10.1.0/admin-guide/index.html#configure-authn-chains'