from the at-least-all-that-telemetry-can-now-be-sent-encrypted dept.
US NIST Unveils Winning Encryption Algorithm for IoT Data Protection
The National Institute of Standards and Technology (NIST) announced that ASCON is the winning bid for the "lightweight cryptography" program to find the best algorithm to protect small IoT (Internet of Things) devices with limited hardware resources:
Small IoT devices are becoming increasingly popular and omnipresent, used in wearable tech, "smart home" applications, etc. However, they are still used to store and handle sensitive personal information, such as health data, financial details, and more.
That said, implementing a standard for encrypting data is crucial in securing people's data. However, the weak chips inside these devices call for an algorithm that can deliver robust encryption at very little computational power.
"The world is moving toward using small devices for lots of tasks ranging from sensing to identification to machine control, and because these small devices have limited resources, they need security that has a compact implementation," stated Kerry McKay, a computer scientist at NIST.
[...] ASCON was eventually picked as the winner for being flexible, encompassing seven families, energy efficient, speedy on weak hardware, and having low overhead for short messages.
NIST also considered that the algorithm had withstood the test of time, having been developed in 2014 by a team of cryptographers from Graz University of Technology, Infineon Technologies, Lamarr Security Research, and Radboud University, and winning the CAESAR cryptographic competition's "lightweight encryption" category in 2019.
More info at the algorithm's Website and the technical paper submitted to NIST in May 2021.
Related:
- NIST Drafts Revised Guidelines for Digital Identification in Federal Systems
- NIST Calls Time on SHA-1, Sets 2030 Deadline
« 2024 Mercedes-Benz eSprinter Electric Van Coming to the U.S. | An AI ‘Engineer’ Has Now Designed 100 Chips »
Related Stories
NIST calls time on SHA-1, sets 2030 deadline:
The US National Institute of Standards and Technology (NIST) says it's time to retire Secure Hash Algorithm-1 (SHA-1), a 27-year-old weak algorithm used in security applications.
"We recommend that anyone relying on SHA-1 for security migrate to SHA-2 or SHA-3 as soon as possible," said NIST computer scientist Chris Celi, in a canned statement on Thursday.
As soon as possible isn't necessarily all that soon: NIST says you should be rid of SHA-1 from your software and systems by December 31, 2030. Meanwhile, the tech industry has largely moved on already.
[...] Despite its known weakness, SHA-1 has shown up in recent years propping up legacy applications and providing shoddy password storage. Microsoft finally got around to dropping SHA-1 from the Windows update process in August 2020.
[...] Celi explains that modules still using SHA-1 after 2030 will be ineligible for purchase by the federal government. Having eight years to submit an update may seem like more than enough time, but Celi warns there may be a backlog of submissions as the deadline nears. Developers wishing to avoid a potential validation delay should submit revised code sooner rather than later.
The draft publication features updates intended to help fight online crime, preserve privacy and promote equity and usability:
The U.S. Department of Commerce's National Institute of Standards and Technology (NIST) has drafted updated guidelines to help the nation combat fraud and cybercrime while fostering equity and preserving fundamental human rights. The guidelines support risk-informed management of people's personas online — their "digital identities" — often required to engage in everyday digital transactions from banking to ordering groceries.
"These guidelines are intended to help organizations manage risks related to digital identity and get the right services to the right people while preventing fraud, preserving privacy, fostering equity and delivering high-quality, usable services to all," said Under Secretary of Commerce for Standards and Technology and NIST Director Laurie E. Locascio. "We are actively seeking feedback not only from technical specialists, but also from advocacy and community engagement groups that have insight into the potential impacts these technologies can have on members of underserved communities and marginalized groups."
[...] NIST is accepting comments on the multivolume draft until March 24, 2023. NIST will host a virtual workshop on Jan. 12, 2023, to provide details on the major changes to the guidelines and the comment process. Interested parties can register online to attend. This will be the first step in a robust engagement process to gain feedback from public and private sector organizations, technology and professional services providers, academia, civil society, advocacy groups and many others on how to improve the draft guidance and achieve a more competitive, secure, private and inclusive identity ecosystem. Among several topics that NIST intends to address, a significant portion of the organization's engagement efforts will be dedicated to exploring emerging and alternative methods of identity verification, including technologies that do not rely upon facial recognition.
(Score: 2) by Frosty Piss on Friday February 10, @11:47AM (1 child)
It will be interesting to discover the built-in NSA back door.
(Score: 2, Disagree) by Rosco P. Coltrane on Friday February 10, @12:06PM
It's right here, hiding in plain sight:
Those two things don't go together, and the NSA has vast computational resources.
But practically they won't have to decrypt anything: all they'll have to do is send a national security letter to the maker of the IoT, who will no doubt collect mountains of data generated by "your" device 24/7, and will comply to the secret police's demands.
(Score: 2) by JoeMerchant on Friday February 10, @11:52AM (5 children)
This is the third time this story has requested my attention in the past few days. Has anyone read into the standard far enough to see if they have public/private key encryption on their list?
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 5, Informative) by janrinok on Friday February 10, @01:22PM
I am still searching for the answer to the question that you specifically asked, however from the linked article we can get:
It seems nobody is expecting it to be resistant to a long term attack although it does perform adequately on low powered devices.
(Score: 2, Informative) by shrewdsheep on Friday February 10, @01:31PM (3 children)
This is a symmetric block cipher. The same key is required for encryption and decryption (see paragraph 2.1 in the spec).
(Score: 2) by JoeMerchant on Friday February 10, @09:35PM (2 children)
Thank you. I suppose you could then implement heavyweight asymmetric encryption to pass randomly generated secret(s), but once you have done that, why not (carefully) use that secret to feed a prng stream as a quasi one time pad for XOR with your data?
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 1) by shrewdsheep on Friday February 10, @10:11PM (1 child)
In a sense this is what cyclic block ciphers do: every block is encrypted with a new key that is deterministically based on the previous key. This avoids problems with encrypting low entropy data (e.g. lots of zeros). Your XOR-idea would have some problems unless you keep your prng a secret. Otherwise you can easiily recover the key from known plaintext.
(Score: 3, Interesting) by JoeMerchant on Saturday February 11, @12:04AM
Modified Mersenne Twister is pretty hard to guess where you are in the sequence, if you handle it properly (enough entropy in the state bits before using it...)
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 3, Touché) by Rich on Friday February 10, @02:27PM (2 children)
This really is a niche product, either the NSA wanted easier access, or someone just spent a nice grant to secure his job with meaningful looking work.
Looking at AVR as a lower bound benchmark for controllers, I see someone got AES 128 at 2300 cycles/block, and AES 256 at 3200 cycles/block. That's about 2 ms worst case for 16 bytes, or one second to completely fill the RAM of the mighty 1284P, or about a tenth of a second for what might be a realistic max. chunk of the 2K of the typical 328. And the AVR is too anemic for anything _I_oT. The most lowly IoT devices today will sport some 32-bit CPU at mid-two-digit MHz numbers, and will easily gobble this stuff away. They'll have to support everything that comes with TLS anyway for at least a pretense of security.
(Score: 4, Interesting) by janrinok on Friday February 10, @08:16PM (1 child)
It is a niche product - but one that is needed. I have designed several IoT items but they all talk directly to my own broker using MQTT. However, the information that they pass is usually in the order of a few bytes, perhaps a reading from a sensor or a combination of bits that indicate the status of a piece of hardware. Without knowing what the bits and bytes actually represent means they a gibberish to anyone else who might read them.
If I want to pass significantly more data securely then I need to be able to encrypt it. An Arduino Uno and other microcontrollers simply have not enough juice for them to use the more common cryptographic packages. This will help solve that problem. I still wouldn't use it for personal information, but at least I could transmit data via a broker that would be more meaningful to the target device. That might help, for example, when sending small packages of data that do not contain a set series of values. I could just send the values that had changed along with a meaningful identifying name so the receiver can easily work out what has been sent. For example, this might be positional data - I might not want someone to know where my device is now, but I don't care if he knows where it was an hour later when my device has moved.
It is of little interest to many people and I don't really care about the government being able to crack it. But it is something that is required by some people, in fact by sufficient numbers of people that justify the fact that this encryption has been funded and is the winner of a contest between half a dozen solutions or so.
That is simply an incorrect assumption. Some of my devices, and many in household items, still use 8 or 16 bit microcontrollers. Why waste a RaspPi when I can achieve the same with an 8 bit microcontroller that only requires a fraction of the power to run and costs next to nothing? There are several technologies (microcontrollers, LORA etc) that make many things possible that a few years ago would have been fantasies.
(Score: 3, Interesting) by Rich on Saturday February 11, @03:23AM
Well, of course you're not going to run OpenSSL with full libcrypto on a 328P. That's what the avr crypto lib is for, and it includes AES. A well tuned algorithm should encode your single block in a millisecond. I just think it's awkward to teach the AVR internet functionality. A ESP8266 module comes at the price of the 328 in PDIP, will easily do all the crypto and networking. It will consume about double the power on average, but that's with the radio on. The 32-bit Micros will draw a bit more when operating, but they will also be finished much faster, not only clockwise, but also from instruction count. If power consumption is an issue, they have deep sleep. (Disclaimer: I have done a lot of work with AVRs, but haven't had anything from Espressif live so far)
Even a proper ARM, STM32F0, can be had for a dollar at 1kU. You'd have to be penny pinching with Puolop and Padauk OTPs to get into a range today where AES is a non-starter. Similarly, the power-per-work is a matter of the process shrink rather than the clock rate (or bit width). Recent STM32L0 (starting at $1.4) can run at a third of the power of an AVR at three times the clock rate (and four times the register width). I stick to AVRs because of convenience and supply issues, but low power or low cost isn't a virtue of them today.
(Score: 5, Funny) by Freeman on Friday February 10, @02:27PM
Both of the developers that were worrying about security on their IoT devices are happy now.
Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"