4

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?

Mark Buffalo
  • 22,498
  • 8
  • 74
  • 91
Nimyz
  • 203
  • 2
  • 5
  • 1
    Can P & H both talk SSL? – Neil Smithline May 08 '15 at 19:47
  • How does H know that P has authenticated with S? How much do you trust H? Specifically, would sending username and password to H put the credentials at risk? – Neil Smithline May 08 '15 at 20:12
  • 1
    Have you looked at SAML? – schroeder May 08 '15 at 20:23
  • @NeilSmithline H can't talk SSL, it is an 8 bit microcontroller – Nimyz May 08 '15 at 20:40
  • @NeilSmithline H knows that P authenticated with S because otherwise P would not be able to send E(nonce|command). This is encrypted using a key that only H and S share but P has no knowledge of. H is trusted but the problem is that it has no way of veryfying the credentials of P I'd want that to be on a central server S – Nimyz May 08 '15 at 20:41
  • @schroeder The problem I think with SAML is that H can only communicate with S through P. Also, the permissions that the the principal (phone) has on the service provider (H) should be stored on the identity provider (S in my case) and should not be the service provider's (H) decision – Nimyz May 08 '15 at 20:42
  • 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 08 '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 08 '15 at 20:55
  • @NeilSmithline H and S share a secret (symmetric) key – Nimyz May 08 '15 at 21:01
  • 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 08 '15 at 21:04
  • There are many modes for SAML, and it can work the way you need it to, at least on a high level. – schroeder May 08 '15 at 21:07

2 Answers2

1

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.

Neil Smithline
  • 14,621
  • 4
  • 38
  • 55
  • 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 09 '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 04 '15 at 23:16
0

  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.

Sunil Agrawal
  • 137
  • 3