Skip to main content
deleted 6 characters in body
Source Link
obareey
  • 117
  • 7

I have a Bluetooth device that sends a small package periodically (without receiving). I want to encrypt and authenticate the data using AES-128. It has an embedded random and unique key which is burned to the memory at production and it is known to the receiver. I have the following message structure:

Counter Payload Magic Padding
4 bytes 10 bytes 4 bytes 2 bytes

Counter is not encrypted and will increment sequentially for each message (never to be repeated) and it will be used as IV to the AES-CTR mode. It will also serve to protect against replay attacks, i.e. older packages will be ignored.

Magic is fixed and known number to check that the decrypted message is not gibberish and a valid data.

Padding is ignored in the receiver side and used to complete the encrypted data to 16 bytes.

Payload + Magic + Padding will be encrypted together before sending, i.e.

Counter Encrypted Data
4 bytes 16 bytes

The questions are:

  1. Can a passive listener break this encryption and/or craft legitimate messages, etc.?
  2. Is this also provide authentication since no one except the key holder can craft such a message?
  3. Is it OK to use IV/nonce with prepending 0 to the Counter? Should I append the counter to a random number (which is also burned at factory)?
  4. What to put to the padding, 0 or random numbers? Is it even necessary?
  5. Is using the magic number this way logical? Do I need to generate random magic and send it both unencrypted and encrypted for validation by the receiver?
  6. What is the correct/well-established method for encryption and authentication in such a setting?

I have a Bluetooth device that sends a small package periodically (without receiving). I want to encrypt and authenticate the data using AES-128. It has an embedded random and unique key which is burned to the memory at production and it is known to the receiver. I have the following message structure:

Counter Payload Magic Padding
4 bytes 10 bytes 4 bytes 2 bytes

Counter is not encrypted and will increment sequentially for each message (never to be repeated) and it will be used as IV to the AES-CTR mode. It will also serve to protect against replay attacks, i.e. older packages will be ignored.

Magic is fixed and known number to check that the decrypted message is not gibberish and a valid data.

Padding is ignored in the receiver side and used to complete the encrypted data to 16 bytes.

Payload + Magic + Padding will be encrypted together before sending, i.e.

Counter Encrypted Data
4 bytes 16 bytes

The questions are:

  1. Can a passive listener break this encryption and/or craft legitimate messages, etc.?
  2. Is this also provide authentication since no one except the key holder can craft such a message?
  3. Is it OK to use IV/nonce with prepending 0 to the Counter? Should I append the counter to a random number (which is also burned at factory)?
  4. What to put to the padding, 0 or random numbers? Is it even necessary?
  5. Is using the magic number this way logical? Do I need to generate random magic and send it both unencrypted and encrypted for validation by the receiver?
  6. What is the correct/well-established method for encryption and authentication in such a setting?

I have a Bluetooth device that sends a small package periodically (without receiving). I want to encrypt and authenticate the data using AES-128. It has an embedded random and unique key which is burned to the memory at production and it is known to the receiver. I have the following message structure:

Counter Payload Magic Padding
4 bytes 10 bytes 4 bytes 2 bytes

Counter is not encrypted and will increment sequentially for each message (never to be repeated) and it will be used as IV to the AES-CTR mode. It will also serve to protect against replay attacks, i.e. older packages will be ignored.

Magic is fixed and known number to check that the decrypted message is not gibberish and a valid data.

Padding is ignored in the receiver side and used to complete the encrypted data to 16 bytes.

Payload + Magic + Padding will be encrypted together before sending, i.e.

Counter Encrypted Data
4 bytes 16 bytes

The questions are:

  1. Can a passive listener break this encryption and/or craft legitimate messages?
  2. Is this also provide authentication since no one except the key holder can craft such a message?
  3. Is it OK to use IV/nonce with prepending 0 to the Counter? Should I append the counter to a random number (which is also burned at factory)?
  4. What to put to the padding, 0 or random numbers? Is it even necessary?
  5. Is using the magic number this way logical? Do I need to generate random magic and send it both unencrypted and encrypted for validation by the receiver?
  6. What is the correct/well-established method for encryption and authentication in such a setting?
one minor mistake; added a tag
Source Link
Patriot
  • 3.1k
  • 3
  • 19
  • 66

I have a Bluetooth device that sends a small package periodically (without receiving). I want to encrypt and authenticate the data using AES-128. It has an embedded random and unique key which is burned to the memory at production and it is known to the receiver. I have the following message structure:

Counter Payload Magic Padding
4 bytes 10 bytes 4 bytes 2 bytes

Counter is not encrypted and will increment sequentially for each message (never to be repeated) and it will be used as IV to the AES-CTR mode. It will also serve to protect against replay attacks, i.e. older packages will be ignored.

Magic is fixed and known number to check that the decrypted message is not gibberish and a valid data.

Padding is ignored in the receiver side and used to complete the encrypted data to 16 bytes.

Payload + Magic + Padding will be encrypted together before sending, i.e.

Counter Encrypted Data
4 bytes 16 bytes

The questions are:

  1. Can a passive listener break this encryption and/or craft legitimate messages, etc.?
  2. Is this also provide authentication since nooneno one except the key holder can craft such a message?
  3. Is it OK to use IV/nonce with prepending 0 to the Counter? Should I append the counter to a random number (which is also burned at factory)?
  4. What to put to the padding, 0 or random numbers? Is it even necessary?
  5. Is using the magic number this way logical? Do I need to generate random magic and send it both unencrypted and encrypted for validation by the receiver?
  6. What is the correct/well-established method for encryption and authentication in such a setting?

I have a Bluetooth device that sends a small package periodically (without receiving). I want to encrypt and authenticate the data using AES-128. It has an embedded random and unique key which is burned to the memory at production and it is known to the receiver. I have the following message structure:

Counter Payload Magic Padding
4 bytes 10 bytes 4 bytes 2 bytes

Counter is not encrypted and will increment sequentially for each message (never to be repeated) and it will be used as IV to the AES-CTR mode. It will also serve to protect against replay attacks, i.e. older packages will be ignored.

Magic is fixed and known number to check that the decrypted message is not gibberish and a valid data.

Padding is ignored in the receiver side and used to complete the encrypted data to 16 bytes.

Payload + Magic + Padding will be encrypted together before sending, i.e.

Counter Encrypted Data
4 bytes 16 bytes

The questions are:

  1. Can a passive listener break this encryption and/or craft legitimate messages, etc.?
  2. Is this also provide authentication since noone except the key holder can craft such a message?
  3. Is it OK to use IV/nonce with prepending 0 to the Counter? Should I append the counter to a random number (which is also burned at factory)?
  4. What to put to the padding, 0 or random numbers? Is it even necessary?
  5. Is using the magic number this way logical? Do I need to generate random magic and send it both unencrypted and encrypted for validation by the receiver?
  6. What is the correct/well-established method for encryption and authentication in such a setting?

I have a Bluetooth device that sends a small package periodically (without receiving). I want to encrypt and authenticate the data using AES-128. It has an embedded random and unique key which is burned to the memory at production and it is known to the receiver. I have the following message structure:

Counter Payload Magic Padding
4 bytes 10 bytes 4 bytes 2 bytes

Counter is not encrypted and will increment sequentially for each message (never to be repeated) and it will be used as IV to the AES-CTR mode. It will also serve to protect against replay attacks, i.e. older packages will be ignored.

Magic is fixed and known number to check that the decrypted message is not gibberish and a valid data.

Padding is ignored in the receiver side and used to complete the encrypted data to 16 bytes.

Payload + Magic + Padding will be encrypted together before sending, i.e.

Counter Encrypted Data
4 bytes 16 bytes

The questions are:

  1. Can a passive listener break this encryption and/or craft legitimate messages, etc.?
  2. Is this also provide authentication since no one except the key holder can craft such a message?
  3. Is it OK to use IV/nonce with prepending 0 to the Counter? Should I append the counter to a random number (which is also burned at factory)?
  4. What to put to the padding, 0 or random numbers? Is it even necessary?
  5. Is using the magic number this way logical? Do I need to generate random magic and send it both unencrypted and encrypted for validation by the receiver?
  6. What is the correct/well-established method for encryption and authentication in such a setting?
Source Link
obareey
  • 117
  • 7

Encryption of small data with fixed key and incremental IV

I have a Bluetooth device that sends a small package periodically (without receiving). I want to encrypt and authenticate the data using AES-128. It has an embedded random and unique key which is burned to the memory at production and it is known to the receiver. I have the following message structure:

Counter Payload Magic Padding
4 bytes 10 bytes 4 bytes 2 bytes

Counter is not encrypted and will increment sequentially for each message (never to be repeated) and it will be used as IV to the AES-CTR mode. It will also serve to protect against replay attacks, i.e. older packages will be ignored.

Magic is fixed and known number to check that the decrypted message is not gibberish and a valid data.

Padding is ignored in the receiver side and used to complete the encrypted data to 16 bytes.

Payload + Magic + Padding will be encrypted together before sending, i.e.

Counter Encrypted Data
4 bytes 16 bytes

The questions are:

  1. Can a passive listener break this encryption and/or craft legitimate messages, etc.?
  2. Is this also provide authentication since noone except the key holder can craft such a message?
  3. Is it OK to use IV/nonce with prepending 0 to the Counter? Should I append the counter to a random number (which is also burned at factory)?
  4. What to put to the padding, 0 or random numbers? Is it even necessary?
  5. Is using the magic number this way logical? Do I need to generate random magic and send it both unencrypted and encrypted for validation by the receiver?
  6. What is the correct/well-established method for encryption and authentication in such a setting?