I'm a masters student in computer science who works part time with my own company as a consultant.

My lastest project is based on my bachelor thesis which handles everything except the security. The application will be audited by a much larger company than those who hired me and one requirement in the audit is dual layer of security on all channels.

The first layer will of course be ssl/tls. As for the second one I've come up with the following.

  • HTTP Digest Access Authentication - for credential exchange
  • DHKE - to create a shared secret that afterwards is used to transport an AES key.
  • RSA - to digitally sign the response from the server to ensure that there is no man in the middle.

My first thought was to use RSA to securely transport the key. But I thought that I could reduce the overhead by using DHKE instead. Correct me if I'm wrong.

The protocol would work something like this:

Client-> (username + public information for DHKE) -> Server
Server-> (B from DHKE, salt for HTTP digest, AES key encrypted with DHKE secret) -> Client
                 (Whole message signed with server private key)
Client-> AES(Hashed information for HTTP digest) -> Server
Server-> AES(Session token) -> Client

Once the session is initiated all messages will be encrypted with the AES key. I am probably overthinking this and missing a lot of details and I would greatly appreciate some advice.

Kind regards Johan Risch

  • What exactly is your question? – Philipp Apr 19 '14 at 19:01

You say this:

one requirement in the audit is dual layer of security on all channels

and that says it all. Your auditors don't understand how cryptography or even security actually works. If they were physicians, they would double doses for all medicines; when they transplant a kidney they would try to hook an extra kidney; when they have to cut off a leg they would remove the other one as well, just to be sure.

Given that the audit is going to be done under such irrational auspices, the best you can hope for is to do something which formally complies to the "dual layer" ritual, but is otherwise harmless enough. This would point at encapsulating two SSL: within a SSL tunnel, just run another one (with distinct algorithms, so that the auditors don't notice how ridicule they are). If you really want to overawe them, use another library for the inner SSL, e.g. OpenSSL on the outside and GnuTLS within.

Making your own implementation of an existing protocol is fraught with perils; designing your own protocol even more so. Don't do it if you can avoid it. Reusing existing protocols and existing implementations will save you a lot of time and yield much fewer vulnerabilities.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.