Vraag

The secret suffix method

  • 26 september 2016
  • 3 reacties
  • 391 keer bekeken

While reading through some of the API documentation of the Developer Portal I stumbled upon the use of the secret suffix method to produce a MAC to authenticate the sender of a payload. It is well known that cryptographers advice against using this method..

What is the rationale for using the secret suffix method instead of an HMAC function (which is designed for this type of thing)?

3 reacties

Reputatie 2
Badge +1
Hi Alex, that's a good in depth question which I will have to consult with the experts. Will get back to you.
Reputatie 2
Badge +1
Hi Alex,

I took some time to be absolutely sure that I understood our experts correctly. Here is their answer:

About the API security of KPN LoRa:
The security of our LoRa API has two layers: SSL and Token authentication.

The first is the SSL layer: for uplink messages our LoRa Core checks if the Application Server has a valid certificate and sets up a secure tunnel. Also, returning downlink traffic should request the certificate of our core and check it for validity before setting up a SSL tunnel. This way the sender of a LoRa message always knows that the receiving end is valid and all traffic is encrypted with SSL.

The second mechanism is the token authentication. A secret key is added to the end of (parts of) the message and put through SHA256 to create a signature token. This way the receiver, who also has this secret key, can check whether the sender is valid. OP remarks that this is a implementation of the ‘secret-suffix’ method, which has a weakness when multiple messages can be caught by a malicious third party. On itself this is true, but since it is combined with a secure SSL connection, these messages cannot be caught by a third party and therefore the weakness cannot be exploited.

That’s why we deemed LoRa safe enough to be used by our customers. Nevertheless, OP is right that it would be even better to use HMAC. We are investigating how to put implement this in the future, possibly together with two-way SSL to add yet another layer of security.
Right, I know it doesn't actually pose a threat. It's just an odd design choice so I figured I'd ask about it. I'm glad you guys are planning to look into it. Thanks for taking security seriously.

Reageer