I have a hardware device (H), phone (P) and web server (S). I would like P to be able to send commands to H, but only if it is authorized to do so. Permissions are stored on server. Technically I could do this with Kerberos, but that seems overkill. The protocol I currently have is the following:

  1. P requests nonce from H (prevent replay attack)
  2. H sends nonce to P
  3. P forwards nonce, along with the command it wants to send to H, to S
  4. If P has permission to execute the command on H, S sends Encrypt(Nonce|Command) to phone. This is encrypted with a key that H and S share in advance. (P authenticates itself to S with username/password)
  5. P forwards Encrypt(Nonce|Command) to H.
  6. H decrypts and verifies nonce. If correct, it executes command.

Is this safe? I know you shouldn't create protocols yourself so I'm curious if this already exists and if it is used in other places?

  • 1
    Can P & H both talk SSL? – Neil Smithline May 8 '15 at 19:47
  • 1
    Have you looked at SAML? – schroeder May 8 '15 at 20:23
  • 1
    If H can't talk to S, can you explain how S knows that the user has authenticated? Is there a shared secret between H & S? Other? – Neil Smithline May 8 '15 at 20:46
  • 2
    @Nimyz 8-bit microcontrollers aren't as flimsy and weak as you might expect. The only thing that stops me running TLS on my Atmega 328P is the fact that it doesn't have enough memory to handle RSA computations on 1024-bit or larger keys. I could probably use an attached SPI/I2C RAM IC for additional memory, but then that'd be much slower, and by that point it's probably just better to use a cheap ARM device with external SRAM instead. Anyway, my advice would be to use HMAC for message signing with a shared secret. – Polynomial May 8 '15 at 20:55
  • 1
    I think that SAML may work. I think I recall it having a ?profile? for the assertion being passed from the provider (S in your example) to the consumer (H) via the user's agent (P). – Neil Smithline May 8 '15 at 21:04

Based on your comments it sounds like S is passing some encrypted or signed access token to P that it passes to H. H can decrypt or verify the token is authentic and use the information contained within to determine of P is allowed to perform the app. That sounds great.

I'm not sure that you need a nonce here if all you are trying to do is prevent replay. You could just use a serial number. Only accept requests that have a higher serial number than the largest one you've seen. This will remove a full round-trip communication and greatly reduce your bookkeeping. If H can lose the current serial number (eg: by rebooting) then maybe you should keep the nonce.

In general, what you're doing sounds pretty reasonable. That said, it would be better if you didn't design and write your own security. Use SAML. It has been extensively studied and is much less likely to have a design or implementation flaw than any solution you can come up with.

  • SAML seems to be based over HTTP/HTTPS. The hardware device will most likely be BLE, NFC,... but not HTTP/TCP so it seems that implementing this would seem like a pain. I'm also curious as to why the above protocol that I described has not been "proven". Basically it is a simple challenge response protocol between (H) and (S) going over a proxy (P). So the question seems to be whether introducing (P) leads to insecurities. – Nimyz May 9 '15 at 13:53
  • How can you make sure that your implementation won't leak it's keys, stores them safely, is immune to all common attacks, and can decode them correctly? Basically it's not that the idea is flawed or unproven(this sounds like very simple token based auth), it is that human error in designing robot brains (is/can be) flawed. – Robert Mennell Nov 4 '15 at 23:16
  1. I assume H is generating nonce with sufficient randomness and is at least 64 bits.

  2. I assume the communication between P and S is over server authenticated TLS.

    • Does H remember the outstanding nonce(s), or just the last one? If it's more than 1, does H expect that the commands be received in order, and receiving them out of order will cause unexpected behavior? You don't have protection against receiving commands out of order.

    • You are using Encrypt(Nonce|Command), rather you should try HMAC(Nonce|Command), as it seems you want integrity and not confidentiality. And using encryption primitives for integrity is not a good idea.

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.