I am using PKCS11Interop to perform Key Management operations inside an HSM. The HSM I am using is a network HSM, Thales N-Shield. Here are the details of my setup:
1- HSM
1- RFS Server
3- Clients
My software application is distributed and is hosted over the 3 clients. The key will be generated in one of the clients and could be used by the application components present in other clients.
However, I have noticed that a key generated in one client machine is not accessible to other client machines until unless both clients do an rfs-sync.
Question: Is there a way to synchronize the client keys with the RFS using some PKCS11Interop API? If No, then in what way I can synchronize the keys between RFS and the Client machine.
I know that an exe can be execute using C# code but doesn't look like a clean apporach.
What you are trying to do is not part of the PKCS#11 standard. So I doubt that PKCS11Interop will be able to achieve this (from looking at its documentation here).
When you generate an object on the token (Thales n-Shield) using PKCS#11 (PKCS11Interop), the Thale's security manager that's installed on the client is actually doing the generation on the HSM. If I remember correctly, the Thales stores these objects on the client machine as flat files encrypted by the security manager's master key. So technically it is not stored on the HSM. This is the reason you have to do a sync with the RFS, and then update your other clients to see the new keys/objects.
You will have to check with the Thales people to see if they can provide a way to automate this. Or you have to implement your own synching mechanism. Since the rfs-sync is a command line tool Thales provides, you will to see if you can execute the commands through C#. Or check with them if they have a C# library that does this for you.
Related
This is a pre-implementation question.
We have a working fabric(2.2) application with an org containing 2 peers, an intermediate CA with TLS enabled and are now planning to implement HSM to store org related private keys. I read from official doc and other articles that to use HSM we need to have PKCS11 enabled docker centOS images and the setup requires a complete rebuild of the binaries and network.
Can we setup HSM w/o disturbing the existing network?
Does peer's couchDB container requires to be reconfigured as well if the answer for Q1 is "yes"?
How do we transfer the available private keys from local MSP keystore to HSM slots?
What are the points to take care while implementing HSM along with TLS/TLS enable existing keys?
Do we have a ready script for this operation in any samples (I did not find it so far)?
(removed point 6 and rearranged)
I have seen very few people talking about implementing HSM with HLF, is there any major issue of usage.
Also please do provide a "take care" points before starting this operation.
Yes, if you have enough peers or orderers running. You will need to restart the peer or order to use HSM one-by-one after setting the environment variable or the yaml file (Or even rebuild the binary with PKCS11). Since you do it one-by-one, other nodes that are running will keep the network alive.
Nope.
Depends on the HSM provider. They will provide you a binary to do that either by GUI or command line, which usually import pkcs12 (cert, public and private key). After import into the HSM, you may remove the private keys from MSP keystore as the Orderer and Peer binary will use the HSM for private key operation. (Of course you should backup them somewhere else)
Key for TLS server or client has to be stored locally. HSM is not supported for TLS yet.
No.
I assume this is same question as number 3
Ya, there exist some issues like the Java Chaincode does not have HSM support and you will need to write the PKCS11 implementation yourself and override the cryptoPrimitive.java.
PKCS11 is a standard interface, not a standard protocol. Each HSM vendor has its own protocol (usually over TCP). They provide a library that speaks their proprietary protocol that you install in your application.
So a HSM is "just" another TCP based service running outside your cluster. To some extent, you connect to an HSM the same way you would connect to a LDAP server:
Get a PIN to the HSM (similar to a password) and store it... somewhere
Install a library (ex: hsm-provider.so) and its configuration file in your environment
Open any firewall, SecurityGroup, VPC and whatnot to ensure TCP/IP connectivity
Let you application talk natively to the device as it would connect to any other serivce.
The specifics (especially local configuration) depend on the HSM provider. Here is a script that configures an HSM emulated in software for Hashicorp Vault. YMMV but this software emulator separates the HSM part from the networking part.
Once you figure out the HSM part, I suggest you look into Utimaco HSM emulator (registration required). You connect to the emulator via a TCP/IP connection, making it as real as can be from Hyperledger's point of view.
I am using Redis to store the access token. I want to know if I need to encrypt the token before saving to redis. If yes then please explain why.I am using C# and Stackexchange.Redis library.
As it is stated in the security section of redis documentation
Redis is designed to be accessed by trusted clients inside trusted environments. This means that usually it is not a good idea to expose the Redis instance directly to the internet or, in general, to an environment where untrusted clients can directly access the Redis TCP port or UNIX socket.
So it is better to secure the instance instead of every individual data in it. Redis doesn't support encryption, as you mentioned you need to handle in application layer. You need to wrap the commands by encrypt/decrypt methods.
For extra security, i think you must use authentication by setting password at configuration file. It can be a long one and will be saved in the configuration file so every command will require auth as a prerequisite.
If your concern is security of the instances communicating with redis, that's another topic. auth will not help just like encryption secret. Since both secrets are in the hand of attacker, he can retrieve the original data.
I'm trying to set up a 2-way SSL connection to an external web service using Oracle Fusion Middleware (a.k.a. SOA Suite). I've googled and even bing'ed my brains out and have found lots of good documentation on creating the JKS, and even some details on adding <property name="oracle.soa.two.way.ssl.enabled">true</property> to the binding.ws element in the composite's XML (all of which I've done). What I haven't found/figured out is how to explicitly state what alias from the JKS to use for that particular connection. This is especially problematic because depending on some key parameters, I need to use one cert rather than another one when establishing that connection (same endpoint, have to pick from 2 different certs). How/Where do I set this up? Is it in BPEL, in the composite? etc.
I've seen code on how to do this in straight Java, but given the visual nature of BPEL and the Composite, I don't know how to tell the system to use a specific key from a key store.
I am faced with a WCF security scenario that isn't particularly well documented online.
I am developing a product licensing service in WCF that will be deployed along with our software (i.e. the service is running on the same PC as the client). This licensing service will be responsible for a number of things related to controlling use of our software and connecting to our remote licensing server for updates, revocations etc. Consequently it's not the kind of service I want spoofed, and I don't really want spoof clients communicating with it either.
As it's running on the same PC as the client can anyone suggest a security policy for this scenario? I'm particularly interested in authentication as most of the other security principles are straightforward. I'm reluctant to get into certificates if I can help it but as mutual authentication is a priority I'm beginning to think I may need to implement a custom 'challenge/verify' scheme between the service and client.
Any ideas? Thanks for reading.
Chris.
My suggestion is that no matter how much effort you put into that, there will be an attack vector that makes all of your effort null and void. One option is to use ILMerge to provide a single dll for your entire application, and store it encrypted on disk and create a loader that hits your service passing in the registration information. On your side, the service will validate the customer information and send back a decryption key. The loader would use the decryption key to decrypt the DLL in memory and load it dynamically.
The shortcoming of this approach is that a determined cracker could debug your application and when the DLL is decrypted, write the unencrypted stream to disk. Your only means of retribution would be to place some kind of marker on the DLL so that you can identify who was responsible for breaking your copy protection and bring legal action if it's found open on the Internet.
As long as you're deploying this software to the client, then you cannot store any kind of key inside it without risking compromise. Even if you use certificates, you cannot hide them from the client while still making them visible to your application. And if you embed the key in the assembly itself then someone will just pop it open using Reflector.
Assuming you don't care about outright cracking (i.e. patching the assembly's code to simply bypass the license checks), then there's one and only one correct way to implement this type of security and that is to mimic the way a PKI works, by using a remote server exclusively.
In a PKI, when a server needs to validate a client via a certificate, it checks that certificate against the certificate authority's CRL. If the CRL reports that the certificate is revoked then it refuses access. If the CRL cannot be contacted then the certificate is considered invalid.
If you want to implement this scenario then you need 3 logical services but not in your current configuration. What you need is a remote licensing server, a client, and an application server. The application server can, theoretically, reside on the client, but the key aspect of this app server is that it performs license checks against the remote licensing service and handles all of the important application logic. That way, "spoofing" the server becomes an almost impossible task because a casual cracker would have to reverse-engineer the entire application in the process.
This is significantly less safe than making the application server a remote server, and may not offer many advantages over simply embedding remote security checks in the client itself and scrapping the local app/licensing server completely. But if you are determined to take this 3-tier approach then the aforementioned architecture would be the way to go.
Again, this is assuming that you aren't worried about "direct" cracking. If you are, then you'll have to read up on techniques specific to that particular attack vector, and understand that none of them are foolproof; they can only slow an attacker down, never stop him completely.
One of my friend is working on issue related to updating expired digital certificates.
He is working on Java application(Swings I guess), which has 4000 clients. All those need a digital certificate to connect to the application and this certificate expires every year.
At the end of year he needs to update the certificate credentials for all clients. Currently this is manual process, done by connecting to each of 4000 systems either locally or by remote connection.
He is got task to convert this process to be an automated process.
Normally the client-side certificate (used by authenticating the client on the server) needs to be passed to the client physically (on the carrier), otherwise, if the certificate is sent via electronic channels, there's a high risk of interception. But if secure connection is used, then the problem becomes less critical.
So the answer depends on how the client-side application is built. The easiest approach would be to add capabilities to refresh the certificate (before it expires) right from the application. The application would request fresh certificate from the server.
If no such capabilities are built-in and there's no way to add them, then the answer would depend on where the client-side application stores the certificate, used for authentication. If it's some file, then automating remote desktop connection using some automation tool would be the only choice.