One-time pad OTP Crypto System [160510]
A logical sequel to RNG-5 hardware random number generator- one-time pad crypto system, very secure, virtually unbreakable peer-to-peer communication!
This is part two in a series about secure communication:
1. Random Number Generator [150116]
2. One-time pad OTP Crypto System [160510] (this article)
3. Tamper-evident paper-mail box for secure distribution of one-time pads
After creating a good random numbers sequence from RNG-5 generator (see Part 1), you can use it as OTP key for peer-to-peer communication. Offline mode - encrypt the message with this device, store it to SD card and send it later. Online mode - OTP encrypted chat-teletype. A small and cheap 7-inch mini-laptop is used as a terminal emulator that communicates with the device thru ATmega328 UART port. The MCU processes de/encryption with OTP key stored on the SD card. Messages are de/modulated with a simple FSK modem, at cca 1000 bps, to be conveyed by ANY device with MIC-in and EAR-out port with a bandwidth of cca. 4000 Hz.
So, the hardware needed for highly secure communication is: 1.) this simple OTP crypto device built around ATmega328, 2.) RNG-5 random number generator, 3.) a cheap 7-inch mini laptop (50-70 EUR), used as a dumb terminal and for management of OTP keyfiles, 4.) a GSM cellphone, a WiFi smartphone with Viber or Skype, a portable VHF/UHF transceiver, anything with half-duplex or even simplex 4kHz audio channel.
There are many overhyped "cryptophones" and crypto software programs available today. The problem is that you can't trust them. Trojanized versions of good programs like PGP (with weakened encryption) and software keyloggers for all kinds of operating systems (that simply leak your plaintext to some IP address) are a common thing. By the year 2020, every computer connected to the internet will have to be considered as compromised. Systems are becomming more and more complex and consequently less and less secure.
This device does all highly critical work inside one Atmega328 MCU with cca 20 kB of firmware. It's written in C, cca. 16 kB of it is FAT32 library, open-source. This is all you need to analyze to confirm its security. It is very difficult to attack. Remove WiFi module from 7-inch laptop, never connect it to the internet again, use it only for this system, and you will have one TRULY SECURE CRYPTO system!
Offline mode is completed and tested. Unencrypted (plaintext) online mode has been tested with ATmega8 thru Skype audio channel and it worked. These two modes need to be integrated to one complete ATmega328 system.
1. Random Number Generator [150116]
2. One-time pad OTP Crypto System [160510] (this article)
3. Tamper-evident paper-mail box for secure distribution of one-time pads
After creating a good random numbers sequence from RNG-5 generator (see Part 1), you can use it as OTP key for peer-to-peer communication. Offline mode - encrypt the message with this device, store it to SD card and send it later. Online mode - OTP encrypted chat-teletype. A small and cheap 7-inch mini-laptop is used as a terminal emulator that communicates with the device thru ATmega328 UART port. The MCU processes de/encryption with OTP key stored on the SD card. Messages are de/modulated with a simple FSK modem, at cca 1000 bps, to be conveyed by ANY device with MIC-in and EAR-out port with a bandwidth of cca. 4000 Hz.
So, the hardware needed for highly secure communication is: 1.) this simple OTP crypto device built around ATmega328, 2.) RNG-5 random number generator, 3.) a cheap 7-inch mini laptop (50-70 EUR), used as a dumb terminal and for management of OTP keyfiles, 4.) a GSM cellphone, a WiFi smartphone with Viber or Skype, a portable VHF/UHF transceiver, anything with half-duplex or even simplex 4kHz audio channel.
There are many overhyped "cryptophones" and crypto software programs available today. The problem is that you can't trust them. Trojanized versions of good programs like PGP (with weakened encryption) and software keyloggers for all kinds of operating systems (that simply leak your plaintext to some IP address) are a common thing. By the year 2020, every computer connected to the internet will have to be considered as compromised. Systems are becomming more and more complex and consequently less and less secure.
This device does all highly critical work inside one Atmega328 MCU with cca 20 kB of firmware. It's written in C, cca. 16 kB of it is FAT32 library, open-source. This is all you need to analyze to confirm its security. It is very difficult to attack. Remove WiFi module from 7-inch laptop, never connect it to the internet again, use it only for this system, and you will have one TRULY SECURE CRYPTO system!
Offline mode is completed and tested. Unencrypted (plaintext) online mode has been tested with ATmega8 thru Skype audio channel and it worked. These two modes need to be integrated to one complete ATmega328 system.
Discussion (13 commentaire(s))
ALMNET il y a 4 ans
Good night!
I created a project file on Atmel Studio 7 and put all source files on it, considering the OTP_crypto_onlne_offline.C as "Main.C" file (I keep the original name), but i have a lot of bugs when compiling the code, all bugs are related to .o files, specially on FAT32 source code.
Do you have an idea about how i can proceed? i tried commenting lines, leaving just the basic code but i got the same result, it can be very helpful if i can get the project folder.
Thanks in advance for your help on this
Regards!
I created a project file on Atmel Studio 7 and put all source files on it, considering the OTP_crypto_onlne_offline.C as "Main.C" file (I keep the original name), but i have a lot of bugs when compiling the code, all bugs are related to .o files, specially on FAT32 source code.
Do you have an idea about how i can proceed? i tried commenting lines, leaving just the basic code but i got the same result, it can be very helpful if i can get the project folder.
Thanks in advance for your help on this
Regards!
Répondre
lux36 il y a 4 ans
Sorry for my late reply, I was busy with other projects and I didn't get an automatic warning on e-mail.
I used AVR Studio 4, ver 4.18, Build 716. I tried installing newer versions, but some problems appeared, so I stayed with this version, because it is good enough.
Seems like you were trying to compile the Atmega328P firmware version, designed for use without Elektor UNO R4. So, you can proceed like this:
1.) Install AVR Studio 4
2.) Open OTP_crypto_onlne_offline.aps project file with it (see the .zip attached)
3.) Under Project->Config options menu, set the optimization to "O2" and other settings as shown in the attachment
See also my discussion with "MoneyChanger" below. The schematics for this version are also attached. After a successful "Build", the results should be like shown in the attachment below - only a few warnings, but no errors.
Elektor UNO R4 uses ATmega328PB, so Elektor people did the compiling based on my source code - this is the version published in the Elektor article - I tested and re-tested it multiple times, of course. Since AVR Studio 4 doesn't have ATmega328PB, I also did my compiling by declaring the project as Atmega328P and modifying the "include" file - I added some ATmega328PB extra registers in it, and I didn't use any of its special ISRs, so this also worked fine.
All depends on which version are you trying to implement- ATmega328P without Elektor UNO R4, or Atmega328PB with Elektor UNO R4.
I hope that this helps, if you have any additional questions, don't hesitate to ask!
I used AVR Studio 4, ver 4.18, Build 716. I tried installing newer versions, but some problems appeared, so I stayed with this version, because it is good enough.
Seems like you were trying to compile the Atmega328P firmware version, designed for use without Elektor UNO R4. So, you can proceed like this:
1.) Install AVR Studio 4
2.) Open OTP_crypto_onlne_offline.aps project file with it (see the .zip attached)
3.) Under Project->Config options menu, set the optimization to "O2" and other settings as shown in the attachment
See also my discussion with "MoneyChanger" below. The schematics for this version are also attached. After a successful "Build", the results should be like shown in the attachment below - only a few warnings, but no errors.
Elektor UNO R4 uses ATmega328PB, so Elektor people did the compiling based on my source code - this is the version published in the Elektor article - I tested and re-tested it multiple times, of course. Since AVR Studio 4 doesn't have ATmega328PB, I also did my compiling by declaring the project as Atmega328P and modifying the "include" file - I added some ATmega328PB extra registers in it, and I didn't use any of its special ISRs, so this also worked fine.
All depends on which version are you trying to implement- ATmega328P without Elektor UNO R4, or Atmega328PB with Elektor UNO R4.
I hope that this helps, if you have any additional questions, don't hesitate to ask!
Répondre
Montrer plus
1 Pièce(s) jointe(s)
1 Commentaire(s)
lux36 il y a 4 ans
This new Labs page layout looks clumsy. I don't know why I can't upload.
Use this MailBigFile link to download:
http://mbf.me/GJ6o4F
Use this MailBigFile link to download:
http://mbf.me/GJ6o4F
Répondre
Montrer plus
1 Pièce(s) jointe(s)
0 Commentaire(s)
MoneyChanger il y a 4 ans
Hello,
Thanks for finding those assets... however, I can't see any of you attachments to your post. Actually I can's see any of the original assets either. They are not showing up like before. I am logged in with my account, but that didn't make any difference. Please advise.
Dan
Thanks for finding those assets... however, I can't see any of you attachments to your post. Actually I can's see any of the original assets either. They are not showing up like before. I am logged in with my account, but that didn't make any difference. Please advise.
Dan
Répondre
Montrer plus
0 Commentaire(s)
lux36 il y a 4 ans
Here it is. This is a variant with ATmega328P. The shield (.bmp file) has connectors compatible to Arduino. However, the main board (.pdf file) probably doesn't have standard Arduino connections - it was designed like Atmega328P board for connection to Crypto shield.
You will probably have to reroute some inputs/outputs inside the firmware to match your variant of Arduino PCB. Hopefully, you will be able to use the Crypto Shield unchanged.
The firmware is designed to work with ATmega328P - 1 hardware UART and 1 SPI. The other UART port is software bitbanged.
Check all the signals one by one...
Good luck!
You will probably have to reroute some inputs/outputs inside the firmware to match your variant of Arduino PCB. Hopefully, you will be able to use the Crypto Shield unchanged.
The firmware is designed to work with ATmega328P - 1 hardware UART and 1 SPI. The other UART port is software bitbanged.
Check all the signals one by one...
Good luck!
Répondre
Montrer plus
1 Pièce(s) jointe(s)
0 Commentaire(s)
lux36 il y a 4 ans
Elektor UNO R4 uses ATmega328PB which has 2xUART and 2xSPI hardware ports. ATmega328PB is available only in SMD version.
I will upload the source code for ATmega328P (which I completed before we decided to convert it to Elektor UNO R4 shield). The other UART is bitbanged by software in this version, and the same SPI is used for SD card and ISP. I don't know about Elegoo UNO R3 pinout, maybe you will have to reroute some pin assignments in the C source code.
I need some time to locate it, then I will upload it.
I will upload the source code for ATmega328P (which I completed before we decided to convert it to Elektor UNO R4 shield). The other UART is bitbanged by software in this version, and the same SPI is used for SD card and ISP. I don't know about Elegoo UNO R3 pinout, maybe you will have to reroute some pin assignments in the C source code.
I need some time to locate it, then I will upload it.
Répondre
Montrer plus
0 Commentaire(s)
MoneyChanger il y a 4 ans
Thank you so much for your reply!
I am trying to use a Elegoo Uno R3 in place of the Elektor R4 that you have in the schematic. Can you confirm that this board has all the necessary features for this project and that you were not using any of the "special" R4 features?
Thanks!
I am trying to use a Elegoo Uno R3 in place of the Elektor R4 that you have in the schematic. Can you confirm that this board has all the necessary features for this project and that you were not using any of the "special" R4 features?
Thanks!
Répondre
Montrer plus
0 Commentaire(s)
lux36 il y a 4 ans
Best regards,
It is nice to hear that you are trying to implement the project.
There is no .ino file because Arduino IDE was never used. I did the programming in Atmel Studio, in C and assembler. These are the only good tools to create a stable code for anything security-critical like a crypto-system.
If you want to change or improve the code, use Atmel Studio for programming, then compile it and flash the MCU through ISP. That is how I did it. For testing you can also use the bootloader:
https://www.elektormagazine.com/labs/elektorino-uno-r4-150790
This way you won't have to remove the shield to plug the ISP connector each time. Remember to erase the bootloader and load the final version through the ISP – the bootloader can easily go berserk and erase a part of MCU's flash memory if the 5V power becomes unstable - read about it in my article.
Arduino IDE (including its bootloader) may be a user-friendly platform for learning to program an embedded system, but it wasn't designed with security in mind, so it shouldn't be used for such applications - the same goes e.g. for BASCOM.
If you are into security and cryptography, here is a reminder, my Tamper-evident Box article has just been published in Elektor:
https://www.elektormagazine.com/magazine/elektor-146/58537
There will be more, like this secure SD-to-SD card copier:
https://www.elektormagazine.com/labs/secure-sd-card-2-sd-card-copier/
Stay tuned. If you have any more questions, don't hesitate to ask.
Répondre
Montrer plus
1 Pièce(s) jointe(s)
0 Commentaire(s)
Guenter Klomann il y a 8 ans
The coding principle is quite simple: You EXOR the data stream and the random data.
This always is working independent of the other communcation layers, and is (mathematically proven) unbreakable, if the random data is really random. I remember, that there are some hardware random generators, which are quite good, but I do not remember the details (Something was described in ELEKTOR or ct a few month ago?)
The second important thing is the exchange of the random data between source and destination (memory space is no problem in these days).
What about a small device, which say "let us exchange our codes" (by NFC or similar) instead of handshake or kissing when you meet your friend?
I think, this is a better project, than optimizing the communication of encrypted data.
This always is working independent of the other communcation layers, and is (mathematically proven) unbreakable, if the random data is really random. I remember, that there are some hardware random generators, which are quite good, but I do not remember the details (Something was described in ELEKTOR or ct a few month ago?)
The second important thing is the exchange of the random data between source and destination (memory space is no problem in these days).
What about a small device, which say "let us exchange our codes" (by NFC or similar) instead of handshake or kissing when you meet your friend?
I think, this is a better project, than optimizing the communication of encrypted data.
Répondre
lux36 il y a 8 ans
My RNG has just been published in March/April 2017 issue of Elektor. I made it because a good hardware RNG is a prerequisite for this OTP crypto device (and for many other systems as well) . You will also find an announcement for this crypto device on page 31 of the same Elektor issue.
I am not very familiar with NFC, I don't know what is its maximum speed of transfer, but the idea is also to make a TEMPEST-proof device in the end. See my discussion with NdK, this will give you an idea what this project is about (with a disregard to that minor misunderstanding at the beginning). Exchanging the codes via NFC is unfortunately VERY susceptable to TEMPEST attacks.
This must be a simple device, with cca 20 kB of firmware that anyone can analyze, difficult to attack by planting a Trojan, by buffer overflow, or by keylogger or any other method that is easy to use on a general purpose PC. The main problem is not the mathematics of cryptography, but its implementation which makes no sense on a highly insecure device like a general purpose PC.
The keys can be easily exchanged by copying the SD card using a small 7-inch mini-laptop used exclusively for this system.
You need to have a full control of your device, make it very simple, keep your keyfiles on your SD card only and handle it very carefully (like your credit card), never connect the 7-inch laptop to the Internet again, and eventually make it TEMPEST-proof to have a highly secure device.
Making it TEMPEST-proof is a difficult task that probably won't be covered in one article. The key idea of the project is simply to make a highly secure crypto device - because as far as I know - such thing is not possible to simply buy of-the-shelf.
Répondre
Montrer plus
1 Commentaire(s)
NdK il y a 8 ans
That's not OTP since the stream is not really random.
Please do not invent (bad) crypto: OTP is secure only if the stream is really random. Using a PRNG makes it really insecure. Much better to use a well-tested symmetric cypher in the right mode (CBC, CFB, GFC or even a simple CM).
Please do not invent (bad) crypto: OTP is secure only if the stream is really random. Using a PRNG makes it really insecure. Much better to use a well-tested symmetric cypher in the right mode (CBC, CFB, GFC or even a simple CM).
Répondre
NdK il y a 8 ans
Cards in the US are not protected. Here in EU there's a smartcard chip that signs the transaction after PIN verification, so it's much harder (even if not impossible) to clone 'em. But money is a strange beast: you can insure it... But if you really need a strong crypto machine it's likely you can't buy an insurance if it fails to protect the secret.
Zeroizing sectors is probably not very effective on flash because of wear leveling algorithms in controller (you can't easily predict if/when a specific sector will be actually reused) and you risk to simply wear out the memory for no real benefit (once the attacker obtains a copy of the card he'll be able to snoop at least every new conversation you're having).
For another cheap but powerful laptop, have a look at https://www.pine64.org/?page_id=3707 ... Using a parallel interface for the display it should reduce emissions, but some tricks with the fonts (reducing contrast and blurring sharp borders) could help, too. An active jammer could bring more attention from who shouldn't notice you...
Zeroizing sectors is probably not very effective on flash because of wear leveling algorithms in controller (you can't easily predict if/when a specific sector will be actually reused) and you risk to simply wear out the memory for no real benefit (once the attacker obtains a copy of the card he'll be able to snoop at least every new conversation you're having).
For another cheap but powerful laptop, have a look at https://www.pine64.org/?page_id=3707 ... Using a parallel interface for the display it should reduce emissions, but some tricks with the fonts (reducing contrast and blurring sharp borders) could help, too. An active jammer could bring more attention from who shouldn't notice you...
Répondre
lux36 il y a 2 ans
I hope you are doing OK. I have published a few more articles in Elektor and a book in the meantime. All my published articles are here:
https://unizg.academia.edu/LukaMatic
Here is my variant of a ChipWhisperer, to be published in Elektor as well:
https://www.elektormagazine.com/labs/poor-mans-chipwhisperer-or-a-smartcard-tweaker
Here is our "Elektor Spy Contest", related to the book:
https://www.elektormagazine.com/labs/the-elektor-spy-contest/
Thank you again for pointing me to Dr. Skorobogatov, his work is a real well of inspiration.
I studied it a lot, especially during writing my book.
How is your life? Everything OK?
https://unizg.academia.edu/LukaMatic
Here is my variant of a ChipWhisperer, to be published in Elektor as well:
https://www.elektormagazine.com/labs/poor-mans-chipwhisperer-or-a-smartcard-tweaker
Here is our "Elektor Spy Contest", related to the book:
https://www.elektormagazine.com/labs/the-elektor-spy-contest/
Thank you again for pointing me to Dr. Skorobogatov, his work is a real well of inspiration.
I studied it a lot, especially during writing my book.
How is your life? Everything OK?
Répondre
lux36 il y a 8 ans
"Analyzing all possible branches of attack tree" may be a subtle (and more professional) way to express something like "delveing into deepest corners of espionage paranoia". But this is exactly what real world security is about. You are right, there is no PFS because the SD card is not protected and thus vulnerable to possible "chambermaid attack".
The SD card will have to be treated carefully, as any other physical token, the same as any credit card. Credit cards handle money and they are even less secure and more difficult to conceal. While I worked on an offshore construction vessel, in Brazil, our chief electrician got skimmed after he simply payed for drinks in a bar. The waiter took his credit card and was away for less than a minute. Of course, he overheard us talking, and realized that a sailor about to spend next month on board a vessel with very slow internet connection was a perfect victim.
But wait, it's easy to implement sector delete routine, to simply erase OTP keyfile bytes of SD card that were used, since every OTP byte can be used exactly once, and this will further increase the security by preventing multiple de/encryptions with the same sequence. Or maybe add some zeroize routine that would fill used spacess with 0x00, than 0xFF and repeat that, e.g. 10 times (at least this was a zeroization standard for hard disks, as far as I remember).
Every SD card contains an internal MCU that handles all low-level jobs, so tweaking with that MCU could be another interesting option. I know about non-standard formatting methods that were used to protect data on 3.5 inch floppy disks in past.
3.5 inch Pi Zero looks neat, but I still prefer 7-inch android laptop (like this one http://www.ebay.com/itm/NEW-7-NETBOOK-MINI-LAPTOP-WIFI-ANDROID-4GB-NOTEBOOK-PC-CHEAP-LAPTOP-/281909468335?hash=item41a31d1caf:g:cPoAAOSwA4dWMZuS), becuse you get keyboard and monitor inside a small and portable case.
TEMPEST attacks are the most fascinating, of course. PS/2 radiates a frequency of max 50 kHz, so an effective 1/4 antenna would have to be about one mile long, and yet you can pick a signal radiated form 0.1% of that length. Radiation of CRT monitor has a very wide frequency span (of unmodulated CVBS video) ranging from 15 kHz to 6 MHz (that's more than 8 octaves-extremely wideband when not modulated to VHF/UHF carrier), but it still works even at 100 meters. Maybe we should invent some "Van Eck raincoat :)" with aluminum padding. Or some kind of "TEMPEST jammer" integrated to crypto device would be even better solution!
Répondre
NdK il y a 8 ans
Well, there's currently no practical way to break EC or AES (or even TEA) encryption (theoretical attacks requiring terabytes of plaintext and the corresponding cyphertext exist, but reduce the keyspace only by some bits, or only allow the breaking of reduced rounds versions of the algorithms). NewHope could be debatable: it's very new so it haven't had years of reviews, but is designed to resist attacks made possible by (still theoretical) quantum computers.
The worst part is that a SD is not protected, so a "maid" could just enter your hotel room while you're having a shower, copy the card and leave completely unnoticed.
Moreover, IIRC your system does not offer PFS: once the card is copied, every old (recorded) conversation encrypted by it is actually plaintext.
Copying a micro usually requires more time and is more tamper evident.
For the terminal: what about a Pi Zero with a 3.5" display (possibly not a SpotPear one: very slow!) ? But remember to consider TEMPEST attacks against various busses (IIRC it's possible to "read" an HDMI signal from some meters away and a keyboard is even easier to intercept, expecially a PS/2 one).
The worst part is that a SD is not protected, so a "maid" could just enter your hotel room while you're having a shower, copy the card and leave completely unnoticed.
Moreover, IIRC your system does not offer PFS: once the card is copied, every old (recorded) conversation encrypted by it is actually plaintext.
Copying a micro usually requires more time and is more tamper evident.
For the terminal: what about a Pi Zero with a 3.5" display (possibly not a SpotPear one: very slow!) ? But remember to consider TEMPEST attacks against various busses (IIRC it's possible to "read" an HDMI signal from some meters away and a keyboard is even easier to intercept, expecially a PS/2 one).
Répondre
lux36 il y a 8 ans
Nice info, thanks. All secret information (OTP keys) will be kept on an SD card and MCU software will be completely open-source, so I shall concentrate on possible attacks that can be mounted WITHOUT possesion of the crypto device itself. This is why I use audio channel (FSK modem, peer-to-peer only) to communicate between two crypto devices, and keep everything away from TCP/IP hardware (Wi-fi circuit will be removed from dumb terminal - mini laptop).
I definitely prefer a teletype to a cryptophone, because nowdays the only secure place to speak would be deep inside a nearby forest...
I definitely prefer a teletype to a cryptophone, because nowdays the only secure place to speak would be deep inside a nearby forest...
Répondre
NdK il y a 8 ans
For a quite complete crypto lib for Arduino: https://rweather.github.io/arduinolibs/crypto.html
Look at Curve25519/P521/NewHope timings (to be counted once per session) and AEAD algorithms section for authenticated encryption.
For a fully open token implementing GnuPG smartcard protocol, have a look at GnuK by Gniibe Yutaka (I bought it from SeeedStudio).
Remember that doing crypto the right way is really hard and requires review by many experts. Usually the naive implementation (easy to check for correctness) is susceptible to side channel attacks (power analysis, timing analisys, etc) and other non-algorithmic attacks (f.e. fault injection), while any good library have already been reviewed (but if it's open you too can review it) and implements countermeasures.
BTW always remember that generic MCUs are not really hardened against determined attackers and can't stand clever or brute-force attacks. F.e. a PIC required from some seconds (for glitch attacks) to a bit less than a couple hours (decapsulation attacks) to reveal the "protected" code, but maybe they improved the defenses a bit. If you're interested you can have a look at papers by Dr Sergei Skorobogatov: http://www.cl.cam.ac.uk/~sps32/
Look at Curve25519/P521/NewHope timings (to be counted once per session) and AEAD algorithms section for authenticated encryption.
For a fully open token implementing GnuPG smartcard protocol, have a look at GnuK by Gniibe Yutaka (I bought it from SeeedStudio).
Remember that doing crypto the right way is really hard and requires review by many experts. Usually the naive implementation (easy to check for correctness) is susceptible to side channel attacks (power analysis, timing analisys, etc) and other non-algorithmic attacks (f.e. fault injection), while any good library have already been reviewed (but if it's open you too can review it) and implements countermeasures.
BTW always remember that generic MCUs are not really hardened against determined attackers and can't stand clever or brute-force attacks. F.e. a PIC required from some seconds (for glitch attacks) to a bit less than a couple hours (decapsulation attacks) to reveal the "protected" code, but maybe they improved the defenses a bit. If you're interested you can have a look at papers by Dr Sergei Skorobogatov: http://www.cl.cam.ac.uk/~sps32/
Répondre
lux36 il y a 8 ans
Yes, I mentioned RNG-5 generator and OTP key stored on SD card but forgot to give a link to the project. Only 15-20 kB of compiled code for Curve25519-donna algorithm inside MCU, looks simple to analyze and confirm its security. I'd prefer to implement it on Atmega328 (to physically separate crypto process from any TCP/IP and Wi/Fi hardware, to keep better control over flow of data and overall security). Nice idea for another project, always welcome.
What do you think about the basic idea of the project (build the crypto device yourself, so you can guarantee its security)? As far as I know, you can't buy such hardware off-the-shelf. Could you tell me if you know about any commercially available ELECTRONIC ( ommiting this word makes electromechanical ENIGMA machine quite acceptable :) crypto-hardware, non-blackboxed, possible to analyze, based on open-source software, with accessible (analog and digital) signal paths ?
What do you think about the basic idea of the project (build the crypto device yourself, so you can guarantee its security)? As far as I know, you can't buy such hardware off-the-shelf. Could you tell me if you know about any commercially available ELECTRONIC ( ommiting this word makes electromechanical ENIGMA machine quite acceptable :) crypto-hardware, non-blackboxed, possible to analyze, based on open-source software, with accessible (analog and digital) signal paths ?
Répondre
NdK il y a 8 ans
Well, having read the linked article (note that you didn't give the link to it in the project description), then yes, I was wrong and it's really OTP. And really impractical as any OTP method is.
A key agreement using Curve25519-donna on a cheap ESP8266 takes about 250ms... Some seconds if you use an ATMEGA328. But then you can encrypt whatever amount of data you want with AES. And all that while keeping the whole private key inside the chip's EEPROM/flash, way harder to compromise (and much more tamper-evident) than a simple SD card.
A key agreement using Curve25519-donna on a cheap ESP8266 takes about 250ms... Some seconds if you use an ATMEGA328. But then you can encrypt whatever amount of data you want with AES. And all that while keeping the whole private key inside the chip's EEPROM/flash, way harder to compromise (and much more tamper-evident) than a simple SD card.
Répondre
lux36 il y a 8 ans
Please think before you talk, that's all I can tell you. Take a better look at my RNG-5 Labs project (No. 150116) https://www.elektormagazine.com/labs/random-number-generator-150116 , read carefully the description of this project and tell me where do you see a PRNG? The OTP key is first generated by RNG-5 (from electronic noise), then the sequence of random numbers recorded on SD card is used for this OTP crypto system. Sequences have been tested and retested (by NIST standard) until 5th prototype was made, which will soon be published in Elektor. You can also see our interview on https://www.elektormagazine.com/news/worldclass-random-number-generator
I am not inventing any new crypto method and I never said so, I am only implementing a well known OTP method on a simple, cheap and secure hardware (and 20 kB of open-source software) that you can't buy off-the-shelf. As I have already said, methods like public key (PGP) are mathematically strong (invented by top experts, that is beyond any discussion here), but the problem is if they are implemented on a general purpose PC (which is extremely insecure nowdays) - then a simple keylogger bypasses everything. The other problem is if they are implemented in a black box (like some cryptophone) - if you don't know both its hardware and software then how do you have any security in your hands?
If you claim that you can re-generate a sequence generated from avalanche noise - and prove that it is actually pseudo-random - then you are really wasting your time here, instead of doing a Ph.D. work on quantum computing...
I am not inventing any new crypto method and I never said so, I am only implementing a well known OTP method on a simple, cheap and secure hardware (and 20 kB of open-source software) that you can't buy off-the-shelf. As I have already said, methods like public key (PGP) are mathematically strong (invented by top experts, that is beyond any discussion here), but the problem is if they are implemented on a general purpose PC (which is extremely insecure nowdays) - then a simple keylogger bypasses everything. The other problem is if they are implemented in a black box (like some cryptophone) - if you don't know both its hardware and software then how do you have any security in your hands?
If you claim that you can re-generate a sequence generated from avalanche noise - and prove that it is actually pseudo-random - then you are really wasting your time here, instead of doing a Ph.D. work on quantum computing...
Répondre
Montrer plus
8 Commentaire(s)
Jack JJo Jouas il y a 8 ans
quand je securise mes acces, certains site avec identifiant /mot de passe sont inaccessible ? (Elektor,EDF,....)
obliger d'enlever les protections ?
PS: la banque ex: LCL paye un espion pendant la session de gestion bancaire qui vend les informations.
(sur Mac et Linux Ubuntu)
C'est bien de chercher une solution de securité mais que faire quand la source refuse,voir Google qui oblige l'acceptation sino rien ?
bon courage dans ce monde de menteurs corrompus.
Jack
obliger d'enlever les protections ?
PS: la banque ex: LCL paye un espion pendant la session de gestion bancaire qui vend les informations.
(sur Mac et Linux Ubuntu)
C'est bien de chercher une solution de securité mais que faire quand la source refuse,voir Google qui oblige l'acceptation sino rien ?
bon courage dans ce monde de menteurs corrompus.
Jack
Répondre
lux36 il y a 8 ans
Hello Jack, thanks for your comment, but I know only the very basics of French and Googletranslate wasn't much help. This was meant to be used only for peer-to-peer comms, both peers need to have the same SD OTP keycard. Skype and GSM have DSP that makes problems, I still need to improve the system to make it stable for these channels, while POTS and VHF-UHF radio channels work well now. Could you please rewrite your comment in English (or Italian, Croatian or Russian) ?
Répondre
Montrer plus
1 Commentaire(s)
Mises à jour de l'auteur
lux36 il y a 4 ans
The Shield remains unchanged, of course.
Verzija_1.5_opet_Atmega328P_softverski_UART.zip (279kb)
lux36 il y a 6 ans
ATmega328PB "include" file (5kb)
lux36 il y a 6 ans
lux36 il y a 6 ans
lux36 il y a 7 ans
modified "include" file, for ATmega328PB (5kb)
Schematics of UNO R4 Crypto Shield, pdf (34kb)
Updated firmware for ATmega328PB, C source code (290kb)
lux36 il y a 8 ans
Includes automatic syncronisation of keypointers of both peers in case of lost tracking. Essential for OTP encryption, to prevent using the same codes twice.
Schematics of final tested prototype, operating in online and offline mode (743kb)
Schematics of final tested prototype, operating in online and offline mode (37kb)
lux36 il y a 8 ans
ATmega328P, open source C code firmware (159kb)
Schematics of offline crypto device, fully tested, drawn in EAGLE (419kb)
Detailed description of offline operation and auxiliary files (404kb)