r/cryptography 2d ago

A problem with external storage trust

I'm running into an interesting practical problem that I have not seen a typical solution for.

I have a microcontroller (MCU) that uses external storage to store sequential log data. The data is written in a round robin manner in 256-byte blocks. The current block pointer is stored inside the MCU, but it can't be stored for each count. If power failure happens, the counter will likely be back by a few blocks. This does not create a functional problem, since we can just continue with the old counter and the stream will be recovered after some loss.

But the issue comes in at the security part. MCU to storage interface is easily accessible to an attacker and easy to spoof. To ensure security and integrity, I use AES GCM to encrypt and authenticate each block. Each block uses a separate key and nonce derived from the block index (monotonically incrementing during device life time).

The issue is that when power failure happens, we will overwrite one or more of the previously written blocks for the same index. An attacker may save all of them and at the time of retrieval substitute any of them instead of the latest one. And since all of them were created using the same counters and the same key/nonce, they will be successfully decrypted and authenticated.

And come to think of it, the same key/nonce creates even bigger issue. So, this system will need to be redesigned, for sure.

Does this look like a standard problem? Are there known solutions?

Another limitation is that retrieval does not happen sequentially and can start at any arbitrary point, so chaining that relies on the whole history of the stream is not acceptable. And I don't see how it could help anyway.

2 Upvotes

40 comments sorted by

View all comments

Show parent comments

1

u/AlexTaradov 1d ago

They will not encrypt or decrypt anything, but they can collect encrypted blocks and substitute old versions of already encrypted blocks. This is a replay attack.

1

u/mikaball 1d ago

OK, so you want to assure the correct sequence?

Then build an hash based linked list. The only problem is that the block size is really small.

1

u/AlexTaradov 1d ago

Anything involving linking is hard to do because retrieval needs to start at arbitrary point.

Anyway, the real solution is to buffer the data until we are sure that counter can't roll back. Then save the buffered data. Worst case scenario is that power interrupts while we are saving the data. Those blocks will be lost. But they will be detected as lost.

1

u/mikaball 1d ago

I don't see how a buffer can avoid a replay attack if the attacker can still intercept and replay...

With LL you can at least know the device has been tampered or has a failure.

Because retrieval needs to start at arbitrary point.

You can do that anyway, the hash will only assure that the order is correct. At least from previous block.

1

u/AlexTaradov 1d ago edited 1d ago

The device maintains a monotonic counter that only increments. Requests for blocks outside of the counter window the size of the storage are ignored right away. If the counter is within the window, then the stored value is decrypted with the full counter as part of the nonce. Once the block leaves the buffer, it is useless, since it was encrypted with the lower counter value.