How to use .NET 4.8 System.Net.Security.SslStream with external device (HSM) that keeps private RSA keys secure, as SslStream.AuthenticateAsServer requires X509Certificate with both public/private keys. How can I associate X509Certificate private key with HSM and pass SslStream validation to the remote secure device?
Is it even possible with microsoft ssl abstraction or should I rely on some custom ssl implementation (open-source library)?
I don't really know you architecture so I'm having issues give a good answer. He are some pointers
1) Whenever you encrypt something you always need to decrypt (or verify). So you always have two copies of the private key. One where it is used to encrypt and the other where it is used to decrypt (or verify)
2) When a key is on a file system you can always protect the file using credentials. But you cannot prevent somebody from remove the hard drive and reading on another system. So a HSM give physical protection of the drive so somebody cannot read your private key on by removing the drive.
3) You system has a red/black boundary where the red area is where data is not encrypted and black is where the data is encrypted. You would have a firewall which is the division between red and black areas. In you case you have three security areas where the third is a violet area (the HSM device) where the private key is protected.
The issue you are having is setting up the red/black/violet boundaries of your system. You have red data that needs to be encrypted with a certificate that is on the HSM. What I think you have is an internal red network (or database) with data that needs to be encrypted with the certificate before being sent out as encrypted black data. So I'm recommending to have a service on the HSM that does the encryption. So your red network to get data encrypted you would send to the encryption service. Then after being encrypted the data could the be sent out the firewall as black data.
Related
I'm tasked with encryption of the network communication of our program and I've been thrown a wrench. I was going to use SslStream but my CTO would like to stay away from managing certificates. So I was wondering is there any other Stream that will encrypt data, or a way to dynamically generate certificates?
You could encrypt your data using a standard encryption algoithm (RSA, AES, PGP, etc.) as long as you control both endpoints. If not, you will need to use something like certificates since clients won't be able to otherwise decrypt. I'm not sure why your CTO would avoid certs, but nonetheless...
See this article for a good start: http://msdn.microsoft.com/en-us/library/0ss79b2x.aspx
Also note that WCF supports MANY means of communication encryption, many of which do not require certs.
WCF netTCPBinding - Is transport encryption enough?
Note finally that you cannot encrypt the message headers if you don't talk directly to the other party (ie: if there's anyone in the middle), since the middle part won't be able to decipher/route your message.
Can i relay on SslStream to encrypt all my sent&received data so i don't have to hash the data or add any other encryption algorithm ?
From MSDN:
Provides a stream used for client-server communication that uses the
Secure Socket Layer (SSL) security protocol to authenticate the server
and optionally the client.
So, on the surface, SSL's function is to provide an encrypted tunnel between client and server. When properly implemented, SSL is considered to be "secure enough" for most operations. This means that you should not need an additional layer of security. However, it also depends upon your application.
I would also like to address another part of your question. "So I don't have to hash the data" - if you hash the data, you are not encrypting it. You are performing a one-way operation that essentially destroys the original data when you send it. Hashes are typically used to see if two or more pieces of data are the same; they cannot be used for symmetric encryption/decryption.
I need to send data between SilverLight applications. I've got requirement that says that data should be transmitted using secure protocol such as SSL/TLS. Data is sent using TCP sockets due to performance reasons. Unfortunately SilverLight doesn't support SslStream. If I want to transmit data over SSL/TLS I need to buy third party library e.g. SecureBlackbox. I don't want to be dependent on third party libraries when it comes to handling transport layer.
However, SilverLight has CryptoStream class. I'm thinking of exchanging the key for symmetric encryption using WCF over SSL (SilverLight supports that) and then encrypt the data with AES using CryptoStream.
Is this solution safe? Can it be compared to using SSL/TLS in terms of security? Is there some obvious security hole that I'm missing?
I guess the main problems with the AES approach is key management and key verification. I'm sure you know that SSL uses a 'handshake', which uses a CA chain (Certificate Authority) to verify the validity of the SSL certificate. This all happens before an AES key is generated for the SSL session. So, by not using SSL, you miss this important step.
This means that you take on the responsibility for verifying that the keys are secure and exchanged in a secure manner.
I am using NServiceBus with MSMQ between my web application and service and I need to be able to encrypt the message payload so that if a message gets queued locally on the web server (service host is down) that sensitive data can't be viewed.
Because the web server is public facing, I am not only required to encrypt data that may be serialized to disk in anyway, but I also cannot store the encryption key on the web server.
I've considered using DPAPI to store the key, but since the key would be stored on the host I don't know yet if that runs afoul of the requirement or not. The other option I have considered is that when the web application starts it could request the key from a service and hold it in memory for the life of the application pool.
I haven't had to work with this level of requirement on encryption before and would like to find out what others are doing and get some feedback on the ideas mentioned above.
Can you use public/private key encryption? Then you only need to public key on the server, and the data is decrypted using the private key elsewhere.
"Because the web server is public facing, I am not only required to encrypt data that may be serialized to disk in anyway, but I also cannot store the encryption key on the web server."
Seems like this is the only constraint to focus on - validate that it is true for starters. It'll rule out DPAPI + local key-store approaches.
It's plausible to deliver the key by service, but that service still has to authenticate the caller. If your server is compromised masquerading as a legitimate caller, observing the call etc. are all possible. In addition if you stored the key only in-memory, that memory is still discoverable in a debugger or memory dump, elevated privilage process etc.
Hardware encryption cards are the only way to overcome the latter scenarios.
You can override the source from which NServiceBus pulls its encryption key - this is described in the docs here: http://docs.particular.net/nservicebus/security/encryption
This way, you can avoid having this sensitive information reside out on the DMZ.
The best place to encrypt is at the queue level. You do this by sending private messages and creating queues that only accept private messages. While you can set the queue privacy level when you create the queue at creation time, I'm not sure if you can configure NServiceBus to send private messages.
I am creating a TCP connect with Flash to a C# daemon.
Now I have come to the part of encryption... I know that Flash is decompilable and so not safe to store private keys on.
I need 2 way encryption because of the messages that have to be send back to the Flash client.
I have been thinking and googling, but cannot find a proper solution yet.
Anybody got an idea??
You'd usually use a hybrid encryption.
Client opens a session on the server, acquiring public key for an asymmetric encryption.
Client generates a key for a symmetric encryption, and sends this key to the server, encrypted with the public key previously acquired.
The rest of the communication is encrypted using a symmetric encryption with they key now known to both client and server.
greetz
back2dos
back2dos' solution will work (and be the easiest) if your connection is SSL/TLS.
If you are forced to use regular sockets (e.g., the server does not have an SSL certificate), then you'll need to do the same by hand. In this case, you'll need to use a Diffie-Hellman key exchange, which enables the creation of a shared secret that is not actually sent over the wire.
Again, if possible, use back2dos' solution. It's a lot easier.