Identified issue by the reviewing team: no data integrity and message replay checking

[kubesajan]

Severity: critical
Risk: high/critical
Problem description: The application does not implement message integrity and replay checking and instead relies on encryption/decryption failing to detect message manipulation. While the fact that sessions are short and decryption is checked to mitigate the issue to some extent, it means that, for example, messages can be held from the card. We have successfully tired this with the functionality for storing data, where we can hold back the encrypted secret and simply report back that we have received the data properly as card (either by replaying the message a card sent previously or sending anything as only return code was checked here.
Additionally, as no message counters or unique data is included in every message, an attacker can observe traffic for identical messages, gaining additional knowledge about the communication.
Remediation: add message counter and hash to plaintext message with synchronization of counters and checking of hash on both ends. Example of new plaintext format: hash || counter || text.
Add these protections to plaintext so they cannot be easily modified.

Overall great work guys, really nice implementation

[NimRo97]

Thank you for the suggestions. Data integrity and message replay are indeed lacking in the implementation.