Sensitive Data


If you need to pass sensitive data over a remoting communication channel across a network, to address the network eavesdropping threat, consider the privacy and integrity of the data. You have three basic choices that are likely to be determined by your deployment environment and your choice of host. Your options include:

  • Using IPSec

  • Using SSL

  • Using a custom encryption sink

Using IPSec

You can use IPSec policies to secure the communication channels to your remote objects, for example, the channel from a Web server. You can use IPSec to encrypt all of the TCP packets sent over a particular connection, which includes packets sent to and from your remote objects. This solution is generally used by secure Internet and intranet data center infrastructures and is beneficial because no additional coding effort is necessary.

The additional benefit of using IPSec is that it provides a secure communication solution irrespective of the remote object host and channel type. For example, the solution works when you use the TcpChannel and a custom host.

Using SSL

If you use the ASP.NET host, you can use IIS to configure the virtual directory of your application to require SSL. Clients must subsequently use an HTTPS connection to communicate with your remote objects.

Using a Custom Encryption Sink

If you do not have a secure data center with IPSec policies that secure the communication channels between your servers, an alternative strategy is to implement a custom encryption sink. You may also want to consider this option if you have a requirement to secure only the sensitive parts of the messages passed from client to server rather than the entire payload. This approach is shown in Figure 13.4.

click to expand
Figure 13.4: Using custom encryption sinks

An encryption sink is a custom channel sink that you can use when you use a custom host with the TcpChannel . On the client side, the sink encrypts request data before it is sent to the server and decrypts any encrypted response data received from the server. On the server side, the sink decrypts the request data and then encrypts response data.

Implementing a Custom Encryption Sink

The sink should use asymmetric encryption to exchange session level encryption keys. After exchanging a session key, the client and server maintain a copy of the key and either side may choose to create a new key at any time during the lifetime of the channel sink. The server should maintain a different key for each client it communicates with.

The following steps outline the basic approach to implement a custom encryption sink:

  1. Create a public/private key pair for the solution.

     const int AT_KEYEXCHANGE =  1; CspParameters cspParams = new CspParameters(); cspParams.KeyContainerName = "<container name>"; cspParams.KeyNumber = AT_KEYEXCHANGE; cspParams.ProviderName = "Microsoft Base Cryptographic Provider v1.0"; cspParams.ProviderType = PROV_RSA_FULL; RSACryptoServiceProvider rsaServerSide = new                                    RSACryptoServiceProvider(cspParams); rsaServerSide.PersistKeyInCsp = true; Console.WriteLine(rsaServerSide.ToXmlString(true)); // Writes the public key 
  2. Expose the public key for clients to consume .

    The client maintains a copy of the public key in a file.

  3. Initialize the client channel sink and create a random key for encryption.

     byte[] randomKey = new byte[size]; RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider(); rng.GetBytes(randomKey); 
  4. Encrypt the random key with the pubic key of your server. Use IClientChannelSink.ProcessMessage to send the encrypted key to the server.

     RSACryptoServiceProvider rsa = new RSACryptoServiceProvider(csp); rsa.FromXmlString("<server's public key>"); AsymmetricKeyExchangeFormatter formatter = new                                     RSAPKCS1KeyExchangeFormatter(rsa); byte[] encryptedSessionKey =  formatter.CreateKeyExchange(_sessionKey); 
  5. Initialize the server channel sink and create an RSA object using the specific key container name.

     const int AT_KEYEXCHANGE =  1; CspParameters cspParams = new CspParameters(); cspParams.KeyContainerName = "<container name>"; cspParams.KeyNumber = AT_KEYEXCHANGE; cspParams.ProviderName = "Microsoft Base Cryptographic Provider v1.0"; cspParams.ProviderType = PROV_RSA_FULL; RSACryptoServiceProvider rsaServerSide = new RSACryptoServiceProvider(cspParams); 
  6. Retrieve the encrypted key from the client. This key is normally sent in the request headers.

  7. Decrypt the session encryption key using the private key of the server.

     AsymmetricKeyExchangeDeformatter asymDeformatter = new                                       RSAPKCS1KeyExchangeDeformatter(_rsa); byte[] decryptedSessionKey =  asymDeformatter.DecryptKeyExchange(                                                          <encrypted key>); 
  8. Use a mechanism for mapping clients to encryption keys, for example, by using a hash table.

At this point, the client and server both share an encryption key, and can encrypt and decrypt method calls. Periodically during the object lifetime, new keys can and should be created.




Improving Web Application Security. Threats and Countermeasures
Improving Web Application Security: Threats and Countermeasures
ISBN: 0735618429
EAN: 2147483647
Year: 2003
Pages: 613

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net