NoAuth

A pragmatic security framework

6 min readAug 27, 2014

Whether you are building a mobile app or want to expose some business logic to your customers, at some point most successful technology companies will have to ask themselves how they are going to secure their communications.

There are few options available, fewer still which are in any way standardised. The major player in the space, OAuth is irreparably broken [1], leaving for some very undesirable options.

NoAuth aims to fill this gap by providing a pragmatic solution to securing communications between devices with technologies that are already well established standards and making as few assumptions as possible. The goal is not to reinvent the security wheel as it were, but to build a framework which seamlessly integrates into today’s technology stacks and remains relevant for years to come.

Design considerations

Public key cryptography

Asymmetric ciphers [2] are unique in the world of cryptography in so far as they require two keys typically called the public and private keys to encrypt and decrypt. Anyone who has remotely logged into a server with their terminal has likely interacted with the concept of public and private keys via SSH.

Briefly, the idea is that when encrypting a piece of data, you have two keys. One key is used to encrypt(sign) while the other is used to decrypt(unsign). This works both ways, one may encrypt with either key and is then able to decrypt with the other key. In public key infrastructure (PKI) it is often assumed that the public key is made (appropriately) public without negatively impacting security.

A particularly useful property of this mechanism is that if a message is signed twice — first with the public key of the recipient and then with the private key of the sender, then we can assure that only the intended recipient is able to read the message and also that the recipient can then authenticate the sender of such a message. This technique is called Enveloped Public Key Encryption (EPKE) [10] .

Additionally, this process consequently means that every message has the quality of non-repudiation. Which is to say that it is known within a reasonable certainty that a given message could not have been sent by anyone else.

NoAuth uses Enveloped Public Key Encryption (EPKE) to ensure authenticity and non-repudiation.

A hybrid approach

Asymmetric ciphers have a major drawback — they are significantly more computationally intensive than an equivalent symmetric cipher. Encrypting a similar message with an asymmetric cipher is typically many orders of magnitude (100x or more) slower than a symmetric equivalent.

As such, if we relied wholly on Public Key Infrastructure to encrypt our messages, we would find that doing so would greatly impact performance. This is to be avoided, of course.

One way we can avoid the costly measure of encrypting an entire message with PKI is to encrypt a part of the message instead of all of it. In this way we can still maintain authenticity of our message without taking on the large performance hit which would other wise be expected.

There is now a serious concern however that since only part of the message is ‘signed for’ that it may be changed in-transit without our knowing. That concern will be addressed later in detail in Digital Signatures.

NoAuth implements a hybrid cryptosystem [3] which optimises for performance without sacrificing security.

Transport layer security

As stated previously, our goal is not to reinvent good and reasonable solutions which already exist. SSL/TLS [4] is one such solution. Widely publicised bugs with one implementation of the protocols aside, it is a very robust and industry accepted standard for providing message secrecy.

As such, we can be reasonably certain that if an attacker listens in on a communication that the conversation is private for as long as they do not have the private key used to encrypt the communications.

Typical implementations of SSL/TLS have a drawback with regards to security concerns: it uses a single key to encrypt communications. This was the fundamental chink in the armour brought out with the HEARTBLEED implementation bug.

Perfect Forward Secrecy [5] is an option in recent versions of SSL/TLS which allow for a new key to be generated on each new connection. Fundamentally this means that if an attacker acquires the private key of a conversation that only that individual conversation may be exposed.

NoAuth requires SSL/TLS with Perfect Forward Secrecy to ensure secrecy.

Digital Signatures

Hash functions [6] are one-way functions (cannot be reversed) which generate a message digest from which an originating message cannot be generated. Message digests such as these can be used to ascertain whether a message has been changed whilst in-transit or not.

The problem with this approach alone is that if an attacker can change the message then they can most likely change the message digest also. What is then required is a Hash-based Message Authentication Code, or HMAC [7]. These work in precisely the same way as one-way hash functions but are also combined with a cryptographic key so that in order for an attacker to generate a valid message digest, they would need to also know the key.

One implementation of such an HMAC conveniently is also a digital signature — by combining the features of public key cryptography discussed earlier with a one-way hash function we can assure data integrity and authenticity at the same time.

NoAuth digitally signs message digests with PKI to create an HMAC that ensures both authenticity and data integrity.

Freshness

The concept of cryptographic freshness [8] is that each message is unique and has an expiration such that should an attacker attempt to resend a message (a replay attack) which has already been sent, that the message could be identified as having expired and therefore would be rejected.

There are three industry-standard ways to achieve this kind of message freshness quality; Timestamps, Monotonic Counters or a Nonce. Each have their own purposes and are generally considered application-specific but since we would like to establish some kind of a standard, it would be in our best interests if one were selected for which had the most relevance and least negative impact.

Timestamps are a pseudo non-deterministic, require clock synchronisation and limit message freshness to a time range. If an attacker is smart enough they can estimate when the next message may be sent or if they are fast enough they can resend the message before the expiration window has elapsed.
Monotonic Counters are deterministic but require minimal overhead and are extremely simple to implement. A monotonic counter is simply a counter which always increases, for instance starting at 1 up to an upper limit such as 2³² (32 bit integer). When the address space is full the counter must never wrap around to zero, instead the conversation must expire and then be re-negotiated.
Nonces [9] (numbers only once) are pseudo-random and non-deterministic. A unique random string of characters are generated for each message which may never be used again during that conversation. A solid implementation requires that each nonce would have an expiration window distinct from itself such that after a period of time it automatically expires.

For practical reasons we select a Nonce as our method of maintaining conversational freshness. Some of the major advantages are:

do not have to devise a potentially complex time synchronisation protocol, thus keeping the protocol as simple as possible.
expiration window (time) can be tweaked on a per-application basis without having a major impact on security.
does not exclude devices which may not have access to accurate time keeping (microcontrollers). This is increasingly important as ‘The Internet of things’ slowly becomes a reality.
is non-deterministic so cannot be predicted in advance. That is assuming of course that the random number generator has a sufficient level of entropy.

NoAuth implements a Nonce mechanism to maintain conversational freshness.

Conclusion

NoAuth uses Enveloped Public Key Encryption (EPKE) in concert with a one-way hash function to generate Digital Signatures and ensures secrecy by communicating over a HTTPS connection with SSL/TLS which has Forward Secrecy enabled. To mitigate against replay attacks, the protocol implements a Nonce mechanism to maintain conversational freshness.

It has the following properties and/or qualities: Secrecy, Authenticity, Non-repudiation, Data integrity, and Freshness.

This is a pragmatic solution to ensuring conversational security between your applications and/or services and third parties. At the very least I hope that you come away from reading this with a better knowledge about the design decisions that are made when developing a secure API. In my next post I will begin to discuss a real-world implementation.

Tell me what you think, contact me on Twitter @sean_nicholls.

References

My ‘bible’ for much of this was ‘Everyday Cryptography’ by Keith M. Martin published by Oxford University Press (May 4 2012) ISBN: 978–0199695591.