I am trying to create a secure Bluetooth Low Energy connection. The peripheral server (the main device other people would connect to) would need to service many clients (users) and due to hardware limitations, I would not be able to let the hardware manage security (essentially, it has a limit of 4 keys, i.e., 4 users).

I have researched and have decided on the following general scheme.

1. Use AES256 for encryption. The key is held in the server and client, assuming that is done securely.

• To do this, the device can generate a random "password" and make it visually appear to the user, which has to enter it on his client device (smartphone). The smartphone, which has generated the AES key would use the password to encrypt the key and send it to the device for storage.

2. Use SHA-256 with a cryptographic key to authenticate messages. I know that this should be done after the encryption.
3. Upon connection, generate an authentication key and send it to the other one.

• I thought about this (not using a static authentication key), so that an attacker cannot record the messages of a session and replay that later. I guess this must be a well-known problem.
• Question 1: How can the key be reliably sent from one to the other?
• Question 2: Who should be the one generating this authentication key? The server device? Or the smartphone?

4. To know which encryption key to use, the userid could be sent in plaintext.

• Question 3: Is it possible not to send userid in plaintext and still be able to understand which key to use for the communication? Does it matter?

5. On each message passing, derive a new authentication key from the previous one.

• I thought about this, so that if an attacker hijacks a session, previously sent cyphered messages in this session would look invalid.
• Question 4: What algorithm could be used to derive a new key from the old one, ensuring that the result is also a "good" key (high entropy and such)?

6. Use an IV to make sure the same message (a command to the server device) encrypts to different messages every time.

• Question 5: Should this also change on every command similar to the authentication key?

Regarding Question 1, during the authentication key exchange, HMAC doesn't seem to be possible, so I was thinking of sending the generated key only encrypted. The other end of the communication can recover the authentication key by decrypting the message. Question 6: could an attacker be able to recover the key by pretending to be on the key-receiving end of the communication? How about if it is pretending to be on the key-sending end?

Regarding Question 2, I am inclined towards having the smartphone generate a key, as it probably has better access to cryptographic libraries (as opposed to the device, which runs on a microcontroller).

Regarding Question 3, I cannot see a problem with an attacker knowing which userid the communication is established with. A system with multiple users with visible ids is, I think, as secure as a system with a single user. Then again, I'm not a security expert.

Regarding Question 4 and 5, I am guessing a pseudo-random number generator seeded with the authentication key/IV should do.

I am trying to create a secure Bluetooth Low Energy connection. The peripheral server (the main device other people would connect to) would need to service many clients (users) and due to hardware limitations, I would not be able to let the hardware manage security (essentially, it has a limit of 4 keys, i.e., 4 users).

I have researched and have decided on the following general scheme.

1. Use AES128 for encryption. The key is held in the server and client, assuming that is done securely.

• To do this, the device can generate a random "password" and make it visually appear to the user, which has to enter it on his client device (smartphone). The smartphone, which has generated the AES key would use the password to encrypt the key and send it to the device for storage.

2. Use SHA-256 with a cryptographic key to authenticate messages. I know that this should be done after the encryption.
3. Upon connection, generate an authentication key and send it to the other one.

• I thought about this (not using a static authentication key), so that an attacker cannot record the messages of a session and replay that later. I guess this must be a well-known problem.
• Question 1: How can the key be reliably sent from one to the other?
• Question 2: Who should be the one generating this authentication key? The server device? Or the smartphone?

4. To know which encryption key to use, the userid could be sent in plaintext.

• Question 3: Is it possible not to send userid in plaintext and still be able to understand which key to use for the communication? Does it matter?

5. On each message passing, derive a new authentication key from the previous one.

• I thought about this, so that if an attacker hijacks a session, previously sent cyphered messages in this session would look invalid.
• Question 4: What algorithm could be used to derive a new key from the old one, ensuring that the result is also a "good" key (high entropy and such)?

6. Use an IV to make sure the same message (a command to the server device) encrypts to different messages every time.

• Question 5: Should this also change on every command similar to the authentication key?

Regarding Question 1, during the authentication key exchange, HMAC doesn't seem to be possible, so I was thinking of sending the generated key only encrypted. The other end of the communication can recover the authentication key by decrypting the message. Question 6: could an attacker be able to recover the key by pretending to be on the key-receiving end of the communication? How about if it is pretending to be on the key-sending end?

Regarding Question 2, I am inclined towards having the smartphone generate a key, as it probably has better access to cryptographic libraries (as opposed to the device, which runs on a microcontroller).

Regarding Question 3, I cannot see a problem with an attacker knowing which userid the communication is established with. A system with multiple users with visible ids is, I think, as secure as a system with a single user. Then again, I'm not a security expert.

Regarding Question 4 and 5, I am guessing a pseudo-random number generator seeded with the authentication key/IV should do.

I am trying to create a secure Bluetooth Low Energy connection. The peripheral server (the main device other people would connect to) would need to service many clients (users) and due to hardware limitations, I would not be able to let the hardware manage security (essentially, it has a limit of 4 keys, i.e., 4 users).

I have researched and have decided on the following general scheme.

1. Use AES256 for encryption. The key is held in the server and client, assuming that is done securely.

• To do this, the device can generate a random "password" and make it visually appear to the user, which has to enter it on his client device (smartphone). The smartphone, which has generated the AES key would use the password to encrypt the key and send it to the device for storage.

2. Use SHA1 with a cryptographic key to authenticate messages. I know that this should be done after the encryption.
3. Upon connection, generate an authentication key and send it to the other one.

• I thought about this (not using a static authentication key), so that an attacker cannot record the messages of a session and replay that later. I guess this must be a well-known problem.
• Question 1: How can the key be reliably sent from one to the other?
• Question 2: Who should be the one generating this authentication key? The server device? Or the smartphone?

4. To know which encryption key to use, the userid could be sent in plaintext.

• Question 3: Is it possible not to send userid in plaintext and still be able to understand which key to use for the communication? Does it matter?

5. On each message passing, derive a new authentication key from the previous one.

• I thought about this, so that if an attacker hijacks a session, previously sent cyphered messages in this session would look invalid.
• Question 4: What algorithm could be used to derive a new key from the old one, ensuring that the result is also a "good" key (high entropy and such)?

6. Use an IV to make sure the same message (a command to the server device) encrypts to different messages every time.

• Question 5: Should this also change on every command similar to the authentication key?

Regarding Question 1, during the authentication key exchange, HMAC doesn't seem to be possible, so I was thinking of sending the generated key only encrypted. The other end of the communication can recover the authentication key by decrypting the message. Question 6: could an attacker be able to recover the key by pretending to be on the key-receiving end of the communication? How about if it is pretending to be on the key-sending end?

Regarding Question 2, I am inclined towards having the smartphone generate a key, as it probably has better access to cryptographic libraries (as opposed to the device, which runs on a microcontroller).

Regarding Question 3, I cannot see a problem with an attacker knowing which userid the communication is established with. A system with multiple users with visible ids is, I think, as secure as a system with a single user. Then again, I'm not a security expert.

Regarding Question 4 and 5, I am guessing a pseudo-random number generator seeded with the authentication key/IV should do.

I am trying to create a secure Bluetooth Low Energy connection. The peripheral server (the main device other people would connect to) would need to service many clients (users) and due to hardware limitations, I would not be able to let the hardware manage security (essentially, it has a limit of 4 keys, i.e., 4 users).

I have researched and have decided on the following general scheme.

1. Use AES256 for encryption. The key is held in the server and client, assuming that is done securely.

• To do this, the device can generate a random "password" and make it visually appear to the user, which has to enter it on his client device (smartphone). The smartphone, which has generated the AES key would use the password to encrypt the key and send it to the device for storage.

2. Use SHA-256 with a cryptographic key to authenticate messages. I know that this should be done after the encryption.
3. Upon connection, generate an authentication key and send it to the other one.

• I thought about this (not using a static authentication key), so that an attacker cannot record the messages of a session and replay that later. I guess this must be a well-known problem.
• Question 1: How can the key be reliably sent from one to the other?
• Question 2: Who should be the one generating this authentication key? The server device? Or the smartphone?

4. To know which encryption key to use, the userid could be sent in plaintext.

• Question 3: Is it possible not to send userid in plaintext and still be able to understand which key to use for the communication? Does it matter?

5. On each message passing, derive a new authentication key from the previous one.

• I thought about this, so that if an attacker hijacks a session, previously sent cyphered messages in this session would look invalid.
• Question 4: What algorithm could be used to derive a new key from the old one, ensuring that the result is also a "good" key (high entropy and such)?

6. Use an IV to make sure the same message (a command to the server device) encrypts to different messages every time.

• Question 5: Should this also change on every command similar to the authentication key?

Regarding Question 1, during the authentication key exchange, HMAC doesn't seem to be possible, so I was thinking of sending the generated key only encrypted. The other end of the communication can recover the authentication key by decrypting the message. Question 6: could an attacker be able to recover the key by pretending to be on the key-receiving end of the communication? How about if it is pretending to be on the key-sending end?

Regarding Question 2, I am inclined towards having the smartphone generate a key, as it probably has better access to cryptographic libraries (as opposed to the device, which runs on a microcontroller).

Regarding Question 3, I cannot see a problem with an attacker knowing which userid the communication is established with. A system with multiple users with visible ids is, I think, as secure as a system with a single user. Then again, I'm not a security expert.

Regarding Question 4 and 5, I am guessing a pseudo-random number generator seeded with the authentication key/IV should do.