I'm building an application with NFC which is a wireless communication protocol. An attacker can modify bits in a wireless communication protocol. I want to prevent this. I know we can't prevent an attacker from changing the wireless signal, but it's possible to detect the modified information.

My question is: is this possible by encrypting your data with e.g. AES? I'm not 100% sure but in my thoughts AES can only be decrypted one way. So if the attacker modifies one or several bits, won't the receiving client be able to decrypt the information?


My understanding of NFC is that, as a standard, it doesn't offer any provision for encryption of data security.

This means you'll have to implement security on top of it.

So first: the important part: do not try to implement it yourself:

  • You do not have the understanding necessary to design it properly (as demonstrated by your question)
  • Even with proper design, implementing security properly is a hard problem even for experience programmers and designers
  • There are plenty of libraries (starting with OpenSSL) that will provide you with the necessary tools for the task, are scrutinized by the best minds in the business for potential weakness and issues (even if old implementation bugs surface from time to time).

Now for the specific part of your question: AES is a bloc cypher. In itself, it does not provide with either authentication or data integrity. All it does is describe how you can use a key to encrypt a single fixed size block of data. You need to couple it with a block cipher mode of operation to add the properties necessary to make it useful in practice: apply it on arbitrary length steam of data, protect against replay attack, data modification, authentication, etc. All these properties depends on the mode of operation you pick.

  • 1
    To be specific, if you choose AES-CBC you'll have block-level malleability allowing you to apply any arbitrary xor tweak to a block (and thus giving you arbitrary modification if you know any plaintext) with the side-effect of corrupting the adjacent block. Or, if you can modify the IV arbitrarily, you can gain xor malleability on the first block with no side-effects. If you choose AES-CTR or any other stream mode, you'll have full xor malleability across the whole stream. So you need authenticity either through MAC or an authenticated mode (e.g. GCM). – Polynomial Oct 6 '14 at 8:43

At least the block where the attacker does the modification, its information will not be recoverable (you'll recover senseless info, be careful on that also because it may have sense even!), but depending on the block cipher mode it could disturb your decryption in a longer set. No information is released on that, but how you react to this issue may release information (thinking on side channels about your time response).

What you seems to want is integrity, and you may like to think on authenticated encryption. You can apply an error handler, not only to detect but also to correct certain level of noise, there are many correct options there. But I insists sooner or later your attacker will force you to resend and it's a big weakness point to be careful for.


That's right, if the attacker modify one or multiple bits of data that encrypted with AES algorithm, it's not possible to decrypt the data on client .

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.