This would use the reverse channel, I assume. Definitively, this would add a lot of security. And no synchronization would be needed.

@@AndreasSpiess , thank you for very interesting and great content. You are my electronic mentor!! I was wondering if it would be possible to use ones mobile device instead of a smartwatch with esp32? Will the mobile phone's wi-fi not be sufficient?

@@peterdever4826 Hi Peter, I think one could use ones phone. The wifi would be more than sufficient. It would require you to run an app of course and your phone would need to make a direct connection to the receiver. The SonOff app does something similar to add a new SonOff to your home network so I don’t see why this couldn’t be done.

can you explain a little more please. I am so interested on this. I am building my own encryption protocol based on Keeloq but since it was defeated by russian hackers I want to build something more robust. My idea is "known command"->encryption+new password for decryption of the next msg-->base64--- transmission ---; Response "ACK" Since the NEXT msg has to be decoded with the password sent in the last msg, a replay attack will fail. the sender always send the password to decode the next encrypted msg. in case on a playback or milk attack, based on the "ack" signals, the sender can hold the last successful msg and send the proper msg to restart. yes is complicated to explain but i swear i will do explain better after my breakfast.

@@soulrobotics One single lost message will desync your devices forever, wouldn't it?

yeah that greater comparison doesn't seem robust to random data too

You should definitely use a checksum in the packet to prevent random data being accepted. You might consider using libnacl for the crypto-stuff. If is available on ESP8266 and ESP32 (here even included in the esp-idf), includes well accepted crypto algoritms, and its "cryptoboxes" do encryption and integrity checking for you.

As many others proposed we could add a simple window of maybe 50 or 100 numbers... Would not be too complicated.

Or pad with a known key phrase, just relying on the number being bigger to be valid is fairly naive approach. There's other ways as well like sending the counter value twice, or send it forward and reversed or adding one to the second copy of the counter value all of which act as very simple checksums that don't require complex maths or libraries.

@@AndreasSpiess Even with protection against random data attacks there's still a vulnerability left - what you mentioned in the video - an attacker that is able to capture a transmission (a transmission that doesn't make it to the receiver endpoint for some reason) can replay it later (until the next successful transmission in range invalidates the captured one). At one hand, this sounds like an unrealistic scenario and can easily prevented by not pressing the button randomly (but only to open the door). At the other hand, an attacker could block the receiver with a jammer/sending random data at the same channel near the receiver and place a second device (to capture an attempt to open the door/has to be placed close to the position of the remote control when transmitting). If the remote control does not work, the owner of the garage will likely open the door using the traditional method (mechanical key...). If he doesn't immediately debug the system and find the cause of the malfunction (maybe decides to look at it next weekend) the attacker now can use the captured transmission to open the garage anytime he wants. So I think the only proper way of implementing a secure protocol is by using a challenge-response algorithm.

You are welcome! I hope this video inspires some people to do something...

Thank you!

Me too :-) And she likes to cover half of my screen...

It is all about education ;-)

Yes, an astonishing number of videos came to existence during the last few years...

Thank you!

Glad you enjoyed it

There are many gadgets around these days (I remember the ESP32 cam, for example). We have way more technology then ideas ;-)

Very good!

Thank you for sharing your experience. Indeed we have many such remotes around us and I wanted to make them a little safer... RFID are also a very useful thing as long as they use the newer ones with some encryption. I think they do not need to be extremely safe because we build one-off devices and if the effort is high, nobody will try it (or smash a window which is easier).

Thank you. This time Dishka was especially lazy and no big help in the lab...

@@AndreasSpiess Seeing her in your video is such a sweet pleasure. I lost my last cat to old age about a year ago and miss him a lot. Give her a scratch for me, she's a real treasure.

I will!

@@cycnus I know how you feel. We lost our Jamie the Fur Monster (Maine Coon Cat) last October after his blessing our lives for 16+ years. AGh, we digressed from sensors!!!

I completely agree and I am not very good at it. Still I think the reach of a system is a big protection factor. If the reach is only a few meters, the effort increases compared with a device connected to the internet. ESP_Now in this respect is probably a good compromise.

My transmitter under the saddle runs all the time. It is so low-power that it does not disturb anybody (range 2 meters or so). But a morse signal with your headlight would be a cool solution ;-)

Good point. Mine is also only rented...

Good point!

Good point. Two way authentication is simple and safe. Unfortunately also an additional effort not everybody likes.

You are right. Or a hammer for a window... Anyway, I never knew how to use encryption and I thought like that I can motivate people to use it for their projects. A little is better than nothing...

Glad you liked it!

Thank you! This time she was so tired I had to film her :-)

Thank you!

You are right. As soon as we establish two-way communication we get much more possibilities.

You are right. If we would add a backchannel we would get a lot of additional possibilities.

Italian subtitles were an automatic translation done by Google. It was a test and maybe I will continue. Thank you for your feedback that the translation was helpful.

Including time is always a very good idea. But then both times have to be synchronized. This could be done during pairing.

@@AndreasSpiess synchronisation is not reallu required, the receiver needs to keep track of the 'latest' message, anything older can be ignored

@@LimBo3500 That leads to a security hole, if your codes get milked and used before you get home and use the genuine remote. Actually without clock sync it's exactly the same approach as with the incrementing numbers. Time IS a steadily incrementing number for PCs and MCUs :-) A synced clock would be a very nice security measure, but you would need to think of the additional energy consumption in the remote as well as clock drift between sender(s) and receiver.

@@zeero4ever Time would allow to set expiricy and you can also sync it during any communication. This would avoid replay attacks outside of the token's validity period.

@@avamander. Thats what I said. Time is useless without sync. Yes you could resync everytime, but it's a pain. If you start implementing two way comms anyway, challenge response would be way easier. You HAVE to know the key and you HAVE to know the logic to calculate the response. No milking or replaying possible, if the challenge uses nonces or some other technique to never have a bitwise duplicate challenge. Otherwise long term eavesdropping COULD make replays possible.

:-)

I do not understand :-(

@@AndreasSpiess Salt in cryptography act as a randomizer. It would encrypt "Hello World" but appear ciphered in many different ways. It prevents to find patterns in ciphered text.

I agree. It probably would shorten the time for the brute force attack. Maybe a random skipping of numbers could already help enough? But keep in mind: There is always a possibility to bang a window ;-)

Very interesting project! I am glad you finally got it working.

Good idea!

Agreed. But you would need two long-time stable clocks... (No problem for a Swiss, of course, but not cheap ;-)

Thank you!

Also a good idea. It seems even safer...

True! She opens one eye a little to check the situation...

Good idea!

Yeah at the very least wouldn't you want some small window like you mentioned for conventional rolling code RCs? So it should only accept values at MAX 250 values ahead of the rx counter?

A window is a good idea and easily done...

You are right. if we add a back channel we get many more possibilities.

You are right: Adding time would tremendously increase security. But it means that we need synchronized clocks on both sides. Not easy to solve, because they have to work for years (assuming the key has no internet access).

@@AndreasSpiess Allowing for a time range (window) to match, should solve the problem of synchronization. Assuming an accuracy of 1 minute/year. A matching range of 10 minutes would allow for 10 years before re-sync would be needed. A range (window) of an hour would allow for 60 years before it failed. If the accuracy was as bad as 6 minutes/year, then you would still get 10 years before failure. If you only send the code once per day then you could even make the time window equal to the usage rate and thus even with very bad clocks, a time window of 24 hours should provide many decades of use before synchronization becomes a problem. The time window just needs to be short enough so that cracking you crypto keys takes longer than the matching time window you allow. I don't think anyone is going to be able to break your AES 128 crypto in 24 hours. :-)

Ja, die ESPs bieten schon viele Möglichkeiten mit Wi-Fi und BLE. Du hast ja schon schöne Projekte gemacht. BTW: Für das S2 board musst du die Experimentelle Version des Arduino Frameworks auswählen.

@@AndreasSpiess Ja danke für den Hinweis, das habe ich schon gesehen. Werde wohl eine zweite IDE aufsetzen, um mir die stabile Version nicht zu zerschießen. Danke für deine Videos!

Ich konnte ohne Weiteres zurück zur normalen Alle Files sind in einem Directory und wenn du sicher sein willst kannst du das jeweils löschen...

You are right with the EEPROMs. Recently they seem to be better and we could rotate the storage of the values to reduce the problem. And I agree, adding two-way communication would open the door for many more concepts.

You are right. Adding a reverse channel definitively would add a lot of security.

@@AndreasSpiess and it does not require synchronization...

You are right. Many solutions are on the search for a problem ;-)

You are right. Adding an uppr limit would be a simple way to increase security. But it is not easy to create even a number without knowing the key...

Exactly what I thought. I'm a simple web-developper just passing by, this is not my field; so I wonder what Andreas thinks about this solution. 🤔

I agree, using time would increase security a lot. But .If you want to use timestamps you need two synchronized clocks on both sides. Maybe not an easy task over years with battery change etc.

@@AndreasSpiess but does your use case require remote situations where there is not the opportunity to resynchronise time over many years (whether the two devices synchronise with each other or synchronise with a common remote NTP server)? Ofcourse, simply maintaining a running clock on the transmitter will increase battery drain as the battery will have to keep powering the clock even when not having anything else to do. Again, this is down to use case, as to whether this is an unacceptable penalty to pay for that use case.

@Hfil66 I decided not to use Wi-Fi for the project. With Wi-Fi, you have many other possibilities, you are right. A simple HTTPS call would have been enough, I think. I also wanted to keep the possibility open to exchange ESP-Now with another communication like 433MHz.

Yes, it is already in its third release...

But the esp looses time tracking without network connection realy quickly... And am rtc clock makes it more difficult

You are right. If you have a good clock inside both devices you can add more randomness to the numbers when you use time stamps. But I am not sure if it is worth the effort in addition to ASE128 encryption. Desynchronization also can happen here (battery dead for example).

Thank you for your additional ideas! I did not know that an internal counter is possible. This algorythm does not have one. The code for a particular message was always the same if I remember right.

Thank you for the tip. It seems the mbedtls can also be used in the Arduino framework. Concerning BLE for light switching: I like this idea. Very strange people were scared. It seems not too hard to understand what happens....

@@AndreasSpiess It's the reason the bean counters gave me. It was in semi rural Africa. Very superstitious.

I know, I know. The content is not important ;-) Just the cat.

Did you already find cheap modules? Last time when I researched the topic a module was still a few hundred dollars :-(

@@AndreasSpiess Yes, as UWB is still a pretty new technology and there are not many manufactures out there producing UBW chips the prices of them are indeed not that cheap at the moment. In my opinion the most interesting chips for makers are the ones from Decawave. Especially the Dev-Board “dwm1001-DEV” looks like it’s a good starting point. Its 21 bugs on mouser atm. www.decawave.com/product/dwm1001-development-board/

My link says more than 200$: www.mouser.ch/ProductDetail/Qorvo/MDEK1001?qs=TiOZkKH1s2TlRZBi6MtMNg%3D%3D This is what I had saw when I searched last time.

The watch is just an ESP32 and a screen. It takes a lot of time to make cool uis even with the libraries, which is why no one does (I didn't). Volos on YT is the man when it comes to cool graphical uses for this watch. He shares all his sketches.

I also posted a link to a project. I agree, it is not easy to create all the interaction and graphics.

Thank you!

Maybe this is possible. Usually, all receivers are jammed at the same time if they are close to each-other. Which is the case if I am in front of my garage and press the button.

@@AndreasSpiess Don't recall the details, but it was documented by some pentest specialist. The most secure way I can think of doing this with amateur MCU project is TOTP, given that you can maintain accurate time source and it won't render your door unusable in case it looses sync.

Unfortunately I am no encryption specialist and cannot follow your idea :-(

@@AndreasSpiess ok, so variable packet length sent, bytes order is length, packet, hash code ( verify data) all encrypted with the same 16+bit length code so the reciever can check it then use the packet command.

Interesting concept. It also should work with one-way communication.

You are right: Wi-Fi is power hungry! My device switches the ESP with a mechanical switch and the CPU switches itself off when done. So the maximum time used is a few seconds per opening. A battery lasts quite long with this method.

I assume it would be hard with this door. Maybe we also could implement a waiting time after a few wrong tries...

I agree, it would be preferable to use the two way communication possibility. When I started the project I wanted to keep it open for other communications like 433MHz (which usually is one way).

The Smartphone does not know the ESP-Now protocol. So we would need another way of establishing a connection. Here I am at the end of my knowledge (how to program Smartphones)

You are right. I think it would not be too complicated to add a „window“ as many viewers suggested.

You are right. A simple and valuable addition.

I am glad to read that you are better now. I thought about you when they showed the horrible pictures in some Indian hospitals. Fortunately, I did not have to go through all this pain. Now I am vaccinated and they say, that, even if I would get it, it should be weaker.

yes it was the worst thing i have seen in my entire life. and even worse it could have been controlled. in my opinion, we had massive political rallies (1million people without masks) because of ongoing provincial assembly elections and village level elections ( we have 3-tier political system here, national level-state level-district/village level). For example one state has 90,000 villages and each one of them is having elections. This urge for power comes from history, especially during medivavl/mughal times and british colonial times, it was feudal and this seat of power was "auctioned" for highest bidder who would in return extract taxes from the local people. Even in 21st century, many people have this kind of thinking in their subconscious mind. in 2020, they had imposed a complete lockdown for about 2-3 months and our economic growth went to -ve range for the first time in 30 years. So this time no lockdown. Had they imposed lockdown in the first week of april for about 10 days, this would not have become such a tragedy. Now they only think about economy and money. Even in my organisation, they started building pressure on me to start working after 10 days...on the other hand those people who i talk to over phone regarding work were also infected. Although we have hospitals but the number of cases were just too many for these hospitals to handle. Most important, this thing develops very fast say in 5-10 days. Although i am far from medical expert, i have to say, this virus looks like a mischief. This is made in such a way that it spreads very fast (i think 10 minute contact is sufficient ) Then it attacks almost all the muscles of body, including lungs, skin stomach, intestine etc..since virus still have no direct cure, medicines have to be given based on where it has attacked which require multi-specialty hospital which are less in number and very costly. Regarding vaccine, my father got a single dose (indian made oxford astrazeneca) but he still got this thing. By god's grace, only mild lung infection (about 5%) was there and lots of weakness. Now recovered. They say right now there is a new variant which is spreading very fast and is genetically different than the one vaccine is designed for. There is a third variant also, which is about 1000 times more contagious and lethal..We do not have pfizer vaccine here, due to legal battle between pharma company and government besides it has to be stored in -70C. As it stands now, 80% get cured at home but with weakness for about a month.... Right now, prevention seems to be the only cure..and i don't know whether economy is more important of human life is. From this entire episode, the only takeaway was that if people were proactive, this would not have escalated to such proportions...Right now we have "micro-lockdowns" and work from home. Not sure what will happen when these restrictions are removed.

Maybe we will even get the new film in the next time when cinemas will open again...

@@AndreasSpiess ...maybe they have to make a new one because in winter time it will be already too old

This seems to be a very special application and also the board is very specialized. So the chance it will appear on this channel is not too big. Unless I find an interesting project for it...

@@AndreasSpiess I see! I agree with that too so I totally understand it :)

I hope you will enjoy it as we do...

With two way communication we would get a lot of possibilities, I agree. And it should not be too complicated.

:-)

You are right. I never understand what she is telling me ;-)

@@AndreasSpiess I had once the same issue. I had a very intelligent tomcat that understood most what we said to him. But we did not understand quite nothing of what he is saying. And he understood that also Which is the intelligent species between us ?

Good points. I thought using a simple encryption call is not too complicated. And concerning Wi-Fi: You are right. There we can use all the internet things. But I wanted to be independent from Wi-Fi and chose ESP-Now which reduces our possibilities.

Other viewers also mentioned it. But so far I did not see examples in the Arduino IDE

@@AndreasSpiess docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/network/esp_now.html look under the security section. These docs are for espidf but the same functions exist in the Arduino sdk

You are right. This would be a simple but useful change.

He sometimes also watches or watched my videos...

:-)

So it is nine years less, you are right ;-)

@@AndreasSpiess , no. I was implying that the computational power must have increased significantly over that time period. Some people built large stacks of video cards for digital currency computations. They can also be used for other purposes.

I agree. (It should have been a bad joke). I anticipated this movement when I only said million years instead of billion years. But, predictions are difficult especially about the future as Niels Bohr once said.

If a BLE device is coupled it sops advertising and is not easily detectable. At least this was the case in my last video.

You are right. If you want to increase the security you must work on this end. I assume it would not be too hard (some string acrobatics). As I said, the code is only a rough sketch.

I thought the library is in the Arduino libraries directory? So people do not need a link. But I will add it if you desire. Concerning a device other than the Smartphone: Then I prefer something like my second example with a button. Having a device transmitting all the time will not have a long battery live, I assume.

@@AndreasSpiess thanks for the link - yes, my Sonoff example uses a button too

:-)

You are right. You get lots of new possibilities if we use a back channel to transmit data from the lock to the key.

if you manage to send something completely random that converts to a readable number, you should truely be granted access :-)

@@zeero4ever It really depends on how you interpret it. You only get bits. You are allowed to read them in anyway you like. If there isn't any constraint on how the bits should look like, they truly are "numbers". If I was given some legitimate counter value and some random number, I wouldn't be able to distinguish them, because there is no rule for me to do so! All I'm saying is one should definitely verify that these numbers are meaningful, and not just accept whatever sequence of bits come out, because again, whatever you put in, you get bits out. Also I should clarify that I am no expert in the field of cryptography, and I have not (yet) read the source code. And as I haven't seen anything that implies these numbers are somehow verified, I assumed they are not. Even sending the value as base-10 numbers in ASCII code and decoding them should be more than enough for this application

​@@erfankhadem7966 You could be right, don't have the AES specs in mind. Does AES know if a data block is garbage or not? If it is just a mathematical transformation based on IV and key, anything could be decoded to (maybe) a high number. But then it would also be sufficient to always include a fixed part, say prefix "CODE" or use 2 following numbers, or the number and the binary complement for parity checking. Let's just say there are million ways to do it kinda secure and million ways to f*ck it up :-)

If you watch the Serial outputs you see that I input a number. The encryption creates a long string which is transmitted. The decryption creates a number again. The AES128 algorythm makes it difficult to do that in reverse without knowing the key.

Yes, I agree. This is equivalent to concatenating a random string (called a nonce) and a command then encrypting. The receiver decrypts, checks it has not seen the nonce previously and performs the command. There are variations: en.wikipedia.org/wiki/Cryptographic_nonce

You would still have to know the correct encryption key.

The idea is, that attacker can't encrypt message because hi don't now key. Hi can only copy a message, so hi can't change any value.

@@zeero4ever it depends how the code is validated. If it only checks whether the integer has increased, you can bruteforce randomly, at minimum, increasing the counter (which at some point will overflow or start at 0 again)

I agree, a number window would be a simple and good addition. But I can assure you to create a number without knowing the key is not simple at all...

It seems to me that if you are sending ONLY a number then @user above is right and you must limit the number of acceptable messages (to 100 for example), otherwise almost any message would be decrypted to a valid message. If you are sending something like "hello world" + number and validating that the decrypted message includes "hello world" then the possible values for the cryptotext is much larger than the set of acceptable messages, and brute forcing is less feasible.

I do not know of such a sensor.

You are right. EEPROMs in the past died quite fast. Newer EEPROMS seem to work longer. But definitively a limitation. You could also every time store the value at a different place in EEPROM.

I truly hope that AES128 is better than you suggest. But I am no specialist.

@@AndreasSpiess wholly depends on your implementation. If it's the same bits being encrypted each time with a static key and only a number is changing Say ID:123 Encrypted is: ajgisjaoqhgix+-19 ID:124 Encrypted is: ajgisjaoqh *h* ix+-19 You only need to find the bit that changes and iterate. At some point: you'll hit ajgisjaoqhhix+-19 Obvs padding, etc has a say but this is why message signing is used or a HMAC. Include a hash of your plaintext message as part of the packet. E.g. HMAC. That way an attacker can fraudulently send messages, but the hash will never match as the attacker will not have the secret key.

I even did not know it has an AES subsystem. Thanks for the info. BTW in a former project I also had issues between the two ESPs because of different representations of variables in the ESP8266 and the ESP32.

@@AndreasSpiess huh, what kind of different representations? Might be this is the problem i have with the interoperability in my implementation.

I do no more remember the details :-( If you use Strings it should work.

@@AndreasSpiess Thanks... will make a test with "only" String Payload...

So far I do not know if anything changes here. The handling fee is also what I think is even not "legal". To charge us to collect taxes is not a good idea, I think. This is not the case for all other taxes.

I assume then the two clocks have to be synchronized from time-to-time. Standard clocks differ after a year or two.

You are right. Accepting all numbers bigger than the current counter is not a good idea. But it should not be too complicated to limit it to the next 10 or 100 numbers only. Is HMAC possible with only a one way communication?

Using time would be a good idea. But you need two synchronized clocks (for a few years).

@@AndreasSpiess GPS seems to be a reliable way of Synchronizing clocks because those satellites use atomic clocks. Only have to worry about propagation delays.

You are right. GPS has very precise time and would be a possibility to get this synchronization

I can imagine that a steel door does not help ;-) Let's hope it works with the antenna. Otherwise maybe you can change the location of the receiver.

Good point!

Personally I think that our one-off designs plus the very limited reach of ESP-Now are the most important protection. The effort to smash a window is always smaller than to hack even a badly protected system. But you are right that the EEPROM will be dead before the end of the numbers...

I only leaned it from my viewers. And I am not sure on how to use it in the Arduino framework.

UKposts now offers an automatic translation if I upload my English script (if I chose to do so). This is why I chose to use it for several languages. What do you think about the quality?

Thank you for the feedback. So, I will continue and see after a few months if some new viewers discovered that they could watch the videos... The current viewers probably do not need them.

@@AndreasSpiess Thanks for the french subtitles! I know a lot of people who have difficulty with english, so it will probably give you some new viewers.

Good point about the header file. With my credentials I have a separate file in my libraries folder that I do not share them accidentally.

I do not know of a built-in encryption. Anyway, I wanted something which could also be used with 433MHz communication for example.