There seems to be a lot of misunderstanding about Web Service security. Using password authentication doesn’t prevent unauthorized users to access your data, while SSL / HTTPS doesn’t give you any information about who is trying to access your services. And did you ever think of signing you messages with a digital signature?
In my introductory post I’ve elaborated on what type of security we’d typically want on Web Services.
In part 1 , I’ve dealt with Username Token authentication, an easy to use way to provide an authentication mechanism for your web service.
In part 2 , I have described Transport Layer Security (TLS) -formerly known as Secure Socket Layer- and message encryption.
In this part, the last one in this series, I will explain how the the digital signature can provide some form of security in web services.
Lets recap the security requirements I have discussed in my introduction .
- The client must be sure it sends it messages to the correct provider;
- The provider wants to be sure that the client is authorized to;
- The provider wants to be sure that the client is who it says it is;
- Both the consumer and provider want to be sure that the messages can only be interpreted by each other;
- Both parties want to be sure that the message sent is received unchanged.
So far, we have dealt with the first four requirements by implementing Encryption or TLS/SSL or by requiring a UsernameToken from the client. But until now, we are still not the guaranteed that the messages are unmodified since we’ve sent them.
Encryption will prevent modification during the transport between the sender and the final recipient, the one with the private key to decrypt the message. However, once decrypted, the message is free to be modified.
Digital invoices are an example of documents that should be digitally signed. In some countries (in The Netherlands in any case) the Belastingdienst (Tax authority) requires that all digital invoices are digitally signed by the company sending the invoice. This way, the Belastingdienst is able to verify who sent the invoice -the one who signed it- and be sure that it hasn’t been tampered with in the meantime. Of course, the company receiving this invoice wouldn’t really mind to have these guarantees too, I suppose.
Now that we have a real valid use case and are really convinces of the need of the digital signature, let’s have a look at how it works.
Actually, it is almost identical to encryption, but then in the opposite way. With encryption, the message is encrypted using the public key. Only the one with access to the private key can decrypt it. When signing, the private key is used to sign the message, and the public key is used to check the signature. Since access to the private key is limited to authorized people/machines, only they can sign the message. Anyone can access the public part of the key -hence “public”-, meaning that anyone can check the signature.
When a message is signed, the actual message itself is not encrypted. That wouldn’t be very meaningful, because that would mean that anyone would have to decrypt the message, even though they might not really care about the signature. Instead, a hash is creating from all the parts that have to be signed. That hash is then encrypted using the private key. The encrypted has is then inserted in (the header of) the message. Typically, one would also include the public key, to allow anyone to check your signature. That’s it.
To check a signature, the hash is recreated the same way as it was done originally and the encrypted hash from the signer is decrypted. If the message has not been tampered with, the newly generated hash and the decrypted original hash are identical. If they are different, you know the message has been tampered with.
The signature on the message will ensure the reader that the message has not been modified since it has signed sent and that the contents were created by, or created with the consent of, the user who signed it. If you want to see it in action, you can download the example code from the Gridshore google code repository. The demo uses all three forms of security described in this series.
This concludes this three-part article about web service security. The type of security you would choose for your web service clearly depends on the needs of your specific service. UsernameToken provides for an easy to use authentication mechanism, while TLS or message encryption prevents a third party from reading the messages. Finally, the digital signature will ensure that a message is not modified after it is signed.