Web Service Security Technologies

Security Technologies in the .NET Framework

The .NET Framework offers support for encrypting and signing data, most notably encrypting any data stream and signing any data stream, with special support for XML data. The latter is provided through support for the World Wide Web Consortium (W3C) standard XMLDSIG.

Once you have agreed on a key to use to encrypt and decrypt data between the two hosts, you can simply encrypt and decrypt using code such as the following, which uses the RC2 symmetric cipher:

static string Encrypt(string plaintext, byte [] key, byte [] IV) {     try {         MemoryStream ms = new MemoryStream();         RC2 rc2 = new RC2CryptoServiceProvider();         CryptoStream s = new CryptoStream(ms,              rc2.CreateEncryptor(key, IV),              CryptoStreamMode.Write);         byte [] p = Encoding.UTF8.GetBytes(plaintext.ToCharArray());         s.Write(p,0,p.Length);         s.FlushFinalBlock();         return Convert.ToBase64String(ms.ToArray());     } catch(Exception) {         return null;     } } static string Decrypt(string ciphertext, byte [] key, byte [] IV) {     try {         MemoryStream ms = new MemoryStream();         RC2 rc2 = new RC2CryptoServiceProvider();                   CryptoStream s = new CryptoStream(ms,              rc2.CreateDecryptor(key, IV),              CryptoStreamMode.Write);         byte [] c = Convert.FromBase64String(ciphertext);         s.Write(c, 0, c.Length);         s.FlushFinalBlock();         return Encoding.UTF8.GetString(ms.GetBuffer());     } catch(Exception) {         return null;     } }

So, rather than simply sending the Web method data across the wire as plaintext, you can encrypt the data and pass it as a Base64-encoded string or send sensitive data back from the server in the same way. Hence, what might be open to “inspection,” such as the following SOAP:

<?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:xsi="http://www.w3c.org/2001/XMLSchema-instance"  xmlns:xsd="http://www.w3c.org/2001/XMLSchema"  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">   <soap:Body>     <GetMeetingResponse xmlns="http://www.fabrikam.com/soap">       <GetMeetingResult>         Meet at Midnight!       </GetMeetingResult>     </GetMeetingResponse>   </soap:Body> </soap:Envelope>

becomes this, which is more secure:

<?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  xmlns:xsd="http://www.w3.org/2001/XMLSchema"  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">   <soap:Body>     <GetMeetingResponse xmlns="http://www.fabrikam.com/soap">       <GetMeetingResult>         LslO+R09UUMziJdQ1Q4P0POzaFxqGHS=       </GetMeetingResult>     </GetMeetingResponse>   </soap:Body> </soap:Envelope>

You achieve this result by simply calling the encryption functions on method exit. For example, this code snippet

[WebMethod] Public string GetMeeting() {     ...     return meetingdata; }

becomes

[WebMethod] Public string GetMeeting() {     ...     return Encrypt(meetingdata, key, IV); }

Notice that it is assumed that the key and initialization vector values have already been negotiated by the two parties.

What Is an IV?

An initialization vector (IV) is a random number, usually with the same number of bits as the encryption algorithm block size, that is used as a starting point to encrypt a set of data.

If IVs are not used, two identical ciphertext messages are generated when two identical plaintext messages are encrypted with the same key. However, if each plaintext message is encrypted with a different IV, the ciphertext messages generated are completely different.

For better security, you should encrypt each message with a different IV, particularly when the messages contain a large amount of duplication. Your application is responsible for transmitting the IV along with the encrypted message. There is no need to encrypt an IV.

The problem with this code is that it requires both ends to have custom code, which is fine if you control the client and the service but not if you want anyone to be able to connect to your service from any client. This brings us to what is on the horizon for Web service security.