3 ms·

These "constrained devices" come up so often in discussions about costs of cryptography, yet people rarely tell what exactly they are talking about. But given t

by hannob 3y ago

These "constrained devices" come up so often in discussions about costs of cryptography, yet people rarely tell what exactly they are talking about. But given that cryptography is usually not very resource intensive to begin with (people often have incredibly wrong ideas about the actual computational costs of cryptography), and we increasingly have more powerful devices even in embedded settings, I doubt this is an actual problem.

DyslexicAtheist 3y ago
> These "constrained devices" come up so often in discussions about costs of cryptography, yet people rarely tell what exactly they are talking about. agree the term is extremely loaded. The closest "official" definition close to a "legal definition" comes out of ETSI 303645. This draft is the basis for what CENELEC is currently using to create an official standard which will become legislation for consumer IoT devices in Europe next year (Radio Equipment Directive / RED). constrained device: device which has physical limitations in either the ability to process data, the ability to communicate data, the ability to store data or the ability to interact with the user, due to restrictions that arise from its intended use NOTE 1: Physical limitations can be due to power supply, battery life, processing power, physical access, limited functionality, limited memory or limited network bandwidth. These limitations can require a constrained device to be supported by another device, such as a base station or companion device. EXAMPLE 1: A window sensor's battery cannot be charged or changed by the user; this is a constrained device. EXAMPLE 2: The device cannot have its software updated due to storage limitations, resulting in hardware replacement or network isolation being the only options to manage a security vulnerability. EXAMPLE 3: A low-powered device uses a battery to enable it to be deployed in a range of locations. Performing high power cryptographic operations would quickly reduce the battery life, so it relies on a base station or hub to perform validations on updates. EXAMPLE 4: The device has no display screen to validate binding codes for Bluetooth pairing. EXAMPLE 5: The device has no ability to input, such as via a keyboard, authentication information. NOTE 2: A device that has a wired power supply and can support IP-based protocols and the cryptographic primitives used by those protocols is not constrained. EXAMPLE 6: A device is mains powered and communicates primarily using TLS (Transport Layer Security). see https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02...
michaelt 3y ago
> These "constrained devices" come up so often in discussions about costs of cryptography, yet people rarely tell what exactly they are talking about. Depending on how difficult you want to be, you can mean different things. If you're being reasonable, you might for example think of a $5 retail price wifi-enabled lightbulb. It might use a chip such as the ESP8266 with 80 KB of memory. Depending on how efficient the SSL library is, supporting 4096-bit RSA on these chips can be a real squeeze, so some SDKs only support 2048-bit. But it's still a 160 MHz chip, so it can run grown-up cryptography. If you want to impose nigh-impossible requirements to torpedo the whole proposal, then demand the cryptosystem work on the tiny sips of power available to contactless bank cards and ten-year-battery-powered smart gas meters; and that it work for automotive door locking where their budget is like $0.02 per chip.
- JoachimS 3y ago
  Exactly this. This is how a lot of industry still operates. In 2024.
JoachimS 3y ago
I've been designing and supporting development of large scale IoT systems the last 15 years. And yes tech progress allows us to afford the use of better algorithms. But customers are still counting every um2 chip area, gates/chip and ROM, code mem in bytes in 2024 to minimize per-device implementation cost. Automotive, a lot of consumer products and large scale SCADA systems are example of systems where these types of questions are at least evaluated during requirement development and system exploration, design. And yes, shaving of a few cents due to being able to use a MCU with 8 kByte RAM instead of 16 kByte can save a lot of money. And it is being done. When I look and crypto algorithms (in a wide sense) I see more utility in having a primitive that provides AEAD, or can be reused n different way to do secure hashing (for integrity, kdf, random generation for example) as well as AEAD, than having lightweight block ciphers. Most lightweight block ciphers have small block sizes, short keys and a lot of rounds. Lyckily there are some nice algorithms that we can trust. And AES is very scalable.

by hannob 3y ago

DyslexicAtheist 3y ago

> These "constrained devices" come up so often in discussions about costs of cryptography, yet people rarely tell what exactly they are talking about. agree the term is extremely loaded. The closest "official" definition close to a "legal definition" comes out of ETSI 303645. This draft is the basis for what CENELEC is currently using to create an official standard which will become legislation for consumer IoT devices in Europe next year (Radio Equipment Directive / RED). constrained device: device which has physical limitations in either the ability to process data, the ability to communicate data, the ability to store data or the ability to interact with the user, due to restrictions that arise from its intended use NOTE 1: Physical limitations can be due to power supply, battery life, processing power, physical access, limited functionality, limited memory or limited network bandwidth. These limitations can require a constrained device to be supported by another device, such as a base station or companion device. EXAMPLE 1: A window sensor's battery cannot be charged or changed by the user; this is a constrained device. EXAMPLE 2: The device cannot have its software updated due to storage limitations, resulting in hardware replacement or network isolation being the only options to manage a security vulnerability. EXAMPLE 3: A low-powered device uses a battery to enable it to be deployed in a range of locations. Performing high power cryptographic operations would quickly reduce the battery life, so it relies on a base station or hub to perform validations on updates. EXAMPLE 4: The device has no display screen to validate binding codes for Bluetooth pairing. EXAMPLE 5: The device has no ability to input, such as via a keyboard, authentication information. NOTE 2: A device that has a wired power supply and can support IP-based protocols and the cryptographic primitives used by those protocols is not constrained. EXAMPLE 6: A device is mains powered and communicates primarily using TLS (Transport Layer Security). see https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02...

michaelt 3y ago

> These "constrained devices" come up so often in discussions about costs of cryptography, yet people rarely tell what exactly they are talking about. Depending on how difficult you want to be, you can mean different things. If you're being reasonable, you might for example think of a $5 retail price wifi-enabled lightbulb. It might use a chip such as the ESP8266 with 80 KB of memory. Depending on how efficient the SSL library is, supporting 4096-bit RSA on these chips can be a real squeeze, so some SDKs only support 2048-bit. But it's still a 160 MHz chip, so it can run grown-up cryptography. If you want to impose nigh-impossible requirements to torpedo the whole proposal, then demand the cryptosystem work on the tiny sips of power available to contactless bank cards and ten-year-battery-powered smart gas meters; and that it work for automotive door locking where their budget is like $0.02 per chip.

JoachimS 3y ago
Exactly this. This is how a lot of industry still operates. In 2024.

JoachimS 3y ago

I've been designing and supporting development of large scale IoT systems the last 15 years. And yes tech progress allows us to afford the use of better algorithms. But customers are still counting every um2 chip area, gates/chip and ROM, code mem in bytes in 2024 to minimize per-device implementation cost. Automotive, a lot of consumer products and large scale SCADA systems are example of systems where these types of questions are at least evaluated during requirement development and system exploration, design. And yes, shaving of a few cents due to being able to use a MCU with 8 kByte RAM instead of 16 kByte can save a lot of money. And it is being done. When I look and crypto algorithms (in a wide sense) I see more utility in having a primitive that provides AEAD, or can be reused n different way to do secure hashing (for integrity, kdf, random generation for example) as well as AEAD, than having lightweight block ciphers. Most lightweight block ciphers have small block sizes, short keys and a lot of rounds. Lyckily there are some nice algorithms that we can trust. And AES is very scalable.