How to transmit data securely?

Question

I’m developing two embedded systems, a supervisor and an agent. The supervisor is a card capable of making connections to the Internet through GPRS. It receives requests from a user, through a web page, and the server transmits data through network sockets to the embedded system. Later I send certain plate information to peripheral devices via radio frequency.

The problem

If this transmission is done in a simple way, anyone can develop a similar hardware and see what is being trafficked. Thinking about it, I used the AES algorithm to encrypt the data. But anyway, if someone repeats this data (even encrypted) may be able to connect devices, open ports and etc. Because the data is sent in binary form, conforms the following image:

A temporary solution I found was to concatenate a set of characters at the end of the package. Thus, even if the "uploaded package" is the same, when this data is encrypted it will be different because of this string. In the agent, save these last received strings so that even if someone repeats the data, no decision is made (I ignore repeated packets).

I recognize that this solution is very, very bad. So researching a little, I found that there is "time synchronization using timestamp". But I do not understand this concept in depth. Does it just consist of adding a time reference to the package so that even if it is repeated the package becomes invalid? Is it possible to do this secure communication without using timestamp? I ask this as a matter of cost, since for each peripheral device I will need a special hardware, a Real Time Clock (Real Time Clock), similar to the figure below:

My doubts are:

1. What is time synchronization (timestamp)?
2. How to transmit data securely?
3. How I could solve this security problem in my application?

Note that I do not ask for code examples. I just wish I knew what I had to do to make this process safe.

Answer 1

What is time synchronization (timestamp)?

I’m not sure if we’re thinking of the same concept, but one technique that uses the watch to bolster security is the "Unique Time-Based Use Password" (Time-based One-Time Password - TOTP). I mention this technique in an answer to my own question about Two Factor Authentication. It is the same method that Google, Facebook etc use in your login system, where the user’s mobile device generates a different code every 30 seconds, and that code has to be provided along with the password to authenticate on an unknown computer.

It is not difficult to implement, no, in reality it is quite simple (with 14 lines of Python made my websites/systems compatible with Google Authenticator). The general idea is as follows:

• One of the participants creates a secret key, and communicates this key to the other participant securely (in your case, the keys can be established at the facility).

• When one participant wants to authenticate with the other, it derives a value from that key and the current time, truncated according to a minimum time interval (in the case of Google Authenticator, the code is valid for 30 seconds).

  • This derivation is simply a HMAC (A code "Message Authenticator" - MAC - Hash-based) current time [truncated] using that common key as key.

• The container takes the local time (also truncated) and re-derives the code by comparing the results. If they’re the same, accept, otherwise reject. It is common to test code 30 seconds in the past and in the future as well, in case the clocks are a little out of sync (this increases the "attack window" a little, to 1 minute and 30 seconds).

The interesting thing about this method is that even if the code is sent in plain text, and an attacker can intercept that code, it’s only valid for 30 seconds and then useless. No matter how many distinct codes the attacker sees, he is not able to figure out what code is expected in a future interaction.

In your case, you can use a range of less than 30 seconds, reject two or more messages in a very short period of time, re-sync the clocks if they are outdated, etc. Each case is a case. But that’s all nay ensures that data security as:

How to transmit data securely?

This depends on what you call "safe", but I will focus on two properties (Disclaimer: the only ones that I’ve studied so far rsrs): confidentiality and integrity/authenticity (ok, these are three properties, but two ways to achieve them).

Confidentiality is usually obtained by encrypting the data. "Perfect encryption" (Perfect Secrecy) is only achieved if each key is used once and then discarded, and only if that key is as long as or longer than the encrypted message (see One-Time Pad). This is nothing practical, but fortunately there is a more relaxed notion of security, called "semantic security", which is satisfied if the opponent’s chance to break it is "negligible".

Block ciphers like the AES provide this semantic security if the message is less than or equal to the block size (128 bits, or 16 bytes) and if you never encrypt the same message twice using the same key. Already Modes of Operation allow messages larger than a block to be encrypted, and the use of some "randomization" (such as CBC Mode Initialization Vector or CTR Mode Nonce) allows more than one message to be encrypted with the same key, including equal messages (which by randomization will generate different ciphers each time they are encrypted).

The problem is that encryption simply protects against passive attacks (Eavesdropping) - where the attacker reads but does not alter communication. Active attacks (tampering) where the attacker can change what is sent between participants, including deciding which messages go and which "get lost in the path" are able to circumvent encryption, even when the algorithm used is effective in providing confidentiality (see Chosen Ciphertext Attack).

Authenticity and integrity are usually obtained using a MAC, already mentioned above. Having a common key between the sender and the recipient, the sender generates a relatively short sequence of bytes (about 80 bits or more should suffice) - called tag - from that message, and sends that tag next to the message, for the recipient to re-compute the value and compare with the tag received. If they are equal, one can assume that the message is legitimate (note: this does not yet protect against replays).

To achieve the three properties, it is therefore necessary to use both encryption and MAC. If you decide to do it in separate steps, always encrypt first and apply the MAC to ciphertext, this as far as I know is always safe (using the MAC first and encrypting everything later is insecure in some cases, and encrypt only the message and send the MAC of the message without encryption is insecure almost always).

There is also the option to use a Authenticated Encryption, such as OCB (notice: patents!), EAX, GCM and CCM. The latter is particularly interesting for you, as the same cryptographic primitive used to encrypt (the AES) is also used to create the MAC - so the total amount of code to be used is reduced. You can also use this method to implement TOTP (if you use it), saving you from including an SHA implementation if you’re not already using it.

How I could solve this security problem in my application?

OK, replays. Well, I have little knowledge of the subject, but I will describe exactly what I know about the protocol TLS (1.2), which solves this issue in a way that - I believe - is satisfactory (if not, I don’t think there is a single secure site in the world):

TLS uses 4 symmetric keys in each session (keys are established during the "handshake protocol", and are ephemeral, but nothing prevents you from using fixed keys - you just lose the Perfect forward secrecy, but this is probably not important in your case). One to "Alice" encrypt to "Bob", another to Alice sign, another to Bob encrypt to Alice and the last to Bob sign (note: by "sign" I mean apply the MAC).

Each exchanged message has a header and a body. The header is not encrypted (it goes in plain text), but is authenticated (it enters the MAC generation). In addition, both sides maintain a pair of counters, representing how many messages (in this case, packages) were sent from one side to the other.

The key point here is that when generating the MAC the message itself is used (reminder: do not do this - encrypt first then create the MAC; in the particular case of TLS is safe, but it is very easy to make a mistake if you do so), the header data, and the accountant representing that message. So that the generated MAC is only valid for that counter, if the attacker resends the package at a future time, the MAC check will fail, because by that time the counter will have changed.

In TLS the counter is implicit (both parties know which is the counter, it is not sent next to the message), and if an error occurs - any error - when decrypting and/or checking the MAC the connection is immediately terminated (without revealing why this occurred) and the handshake protocol needs to be done again to reestablish the connection. This is to block whichever type of attack, and since in TLS a new key is created on each connection, any advantage the attacker had at the time the protocol failed should be undone.

As you can apply this to your case, I won’t risk giving an opinion. Cryptography is a very complex subject (as mentioned by Eduardofernandes in his reply), and I still don’t have enough knowledge to propose something that then doesn’t turn out to have a horrific flaw... From the top of my head, the option I would explore would be at the time of authentication (the devices mutually authenticate, right?) they combine into a session identifier (unique, randomly generated by the participant with more resources - probably the server) and a counter, and each message include in your MAC generation these two values. As two messages will never repeat the two values at the same time (in the same session, increasing counters; in different sessions, distinct Ids) an attack of replay will not be possible.

I would still need to think about it a bit (I would like the opponent to interfere at the time when that session ID is negotiated? Hmmm...) but at the moment it’s all I have to contribute.

Answer 2

Understand that cryptography is a dense subject that requires a lot of study. I will try here to answer your questions succinctly.

1 - What is time synchronization?

In fact this is one of the ways of synchronization using a variable element called "nonce". When you encrypt a message, it will always have the same result. This allows several forms of attacks to the same, since messages transmitted should never be the same, even if they are from the same origin. To avoid this one uses an element, the "nonce", which is nothing more than a variable value added to the encrypted element. In this way, the same entity generates different messages that are trafficked. The receiver must know the "nonce" used and one of the ways to generate variable values is to use timestamp, a measure that always changes. Note that in order for the receiver to decipher the message it needs the "nonce" which can be sent in a decrypted form.

Note that instead of using timestamp you could use a counter, which is incremented on both sides of both the sending entity and the receiving encrypted message.

2 - How to safely transition data?

In the part of the circuit that sends the signal, you create a "nonce" of timestamp, encrypt the: "nonce" + message using your AES algorithm and send the timestamp + message encrypted with nonce + message. Your receiver, knows the "nonce" as it was sent and can decrypt the message.

3 - How I could solve this security problem in my application?

Just follow step 2.

Note that instead of using timestamp, you could use a counter that increases equally on both sides. This counter would be your "nonce" and this would not need to be transmitted.

Behold that article which explains well the issue of "nonce" using counters and timestamp.

Already that answer of Crypto Stack Exchange explains well the difference between key, IV and "nonce".