1

I have a small device with a 16-bit (embedded) architecture, which transmits 1500 bytes every 3 milliseconds. This device has no built-in integrity protection, and it is possible to manipulate the data sent from this device. I was thinking of protecting the data integrity using HMAC or Blake2, but the problem is that these methods are slow for my application and due to the time constraint I cannot do a full pass over the data. I understand that I need to make a compromise between speed and security. I was thinking of the following two solutions:

1) to randomly select a smaller chunk of data and do integrity check; or

2) to use a fast checksum method.

I was wondering if there would be a better solution. I will appreciate your insights.

|improve this question
  • 1
    I don't see how randomly verifying data would help. If all data is sensitive, then the attacker will change other data, or try the same change again and again until it evades the verification. Can you identify more sensitive subsets of the data? The setup isn't fully clear to me: is the device generating the data (and calculating its integrity check value), or is it verifying the integrity of what it receives? – Gilles 'SO- stop being evil' Mar 8 '16 at 19:17
  • in each session I hash a randomly selected chunck, which is different from the previous session. Doesn't this pause the adversary for a while? – Jolfaei Mar 8 '16 at 19:22
  • It might pause the adversary for a session at most. – Gilles 'SO- stop being evil' Mar 8 '16 at 19:24
  • @Gilles, it's a kind a measurement device that calculates some values (can calculate its own integrity check values) and send them to the network. This device has a tamper-proof key. – Jolfaei Mar 8 '16 at 19:31
  • Well, CRC is a step up from simple checksum in verifying against noise error. If the problem is to provide true crypto against human interference, then there are a lot of other factors to consider. If it's a connectionless stream of packets, implementing a crypto check a packet at a time will still leave open things like replay attacks. So the question should probably include more details about how the connection is implemented, and what kind of fuzzing is being worried about – user103817 Mar 8 '16 at 19:34
0

You could use the Fletcher16 algorithm and - not really very secure at all, but still - provide it with a "secret" IV, if feasible.

BLAKE2 boasts pretty good speeds, so if you can't use it I'm afraid MD5-class security is unattainable -- all comparable alternatives would be even slower.

Reordering the data so that sensitive information is gathered together and Blakeing that block might be feasible, perhaps.

Or you could prepare a block with a device secret and a copy of the few fields you want to protect, then send the packet together with the BLAKE2 hash of the check block, which would not be sent.

Relying on security through obscurity (needless to say, not recommended) you could append to the packet the N-bit XOR of the key fields; or a random N-bit value plus the XOR of the key fields and the random value, yielding an apparently random 2N-bit field.

|improve this answer

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.