Siz istediniz biz uzattık! İndirimli bilet fiyatları için son tarih: 29 Mart!

00 Gün
00 Saat
00 Dakika
00 Saniye

security

  • Trusted Platform Modules: 8 Surprises for IoT Security

    Trusted Platform Modules are poorly understood by many, well understood by few.

    Built into billions of devices, a Trusted Platform Module (TPM) is usually a specialized chip on an endpoint’s motherboard that stores cryptographic keys on behalf of its host system for authentication and protection of the endpoint. Each TPM chip contains one or more unique key pairs, certified by the vendor, called endorsement keys (EKs), for validating the TPM’s authenticity. A TPM can also store platform “measurements” that identify software and firmware running on the platform. To stop the TPM from protecting the system, a hacker would have to interfere with it physically. In addition to their popularity on the PC and network side, TPMs will be architected into billions of Internet of Things devices.

    Surprise 1: TPMs are passive, not active devices. They do not control anything on the host system they are embedded on.

    A widespread misconception is that a trusted platform module somehow controls the system it’s a part of, but a TPM is 100 percent passive with respect to the rest of the system.

    The trusted platform module is a self-contained component that has its own storage and processing capabilities, which it uses for protected operations on internal resources such as keys and measurements. These resources, however, are data that are given to the TPM, or that it is asked to generate.

    Typically, boot code uses the TPM to store measurements of software running on the system, and applications use the TPM to protect the application’s keys and report measurements. These activities are all externally driven, not initiated by the TPM.

    Surprise 2: A TPM is only useful when other things in the device take advantage of it.

    The TPM is part of a broader security ecosystem that includes everything from the BIOS to motherboards to account passwords. To obtain value from the TPM, system designers must create systems that rely on the TPM’s internal resources. In traditional TPM implementations, software is “measured” before it is run in order to identify rogue software. The measurements are stored in the TPM, giving it second-hand awareness of “bad” software. The TPM will protect keys it holds, refusing access to rogue software that does not meet the expected measurements. For example, for solutions like Microsoft Bitlocker, an attacker booting to the wrong OS could not decrypt data on the hard drive. Similarly, a TPM might not allow a key to be used to authenticate a device to a bank, preventing an attacker from unauthorized account access.

    With proper integration, a TPM can support the security of billions of future IoT devices that would otherwise be difficult to protect. By creating system dependencies on a TPM for devices like automotive electronic control units (ECU), system designers can make it much more difficult to swap out a system component without detection.

    Surprise 3: A TPM doesn’t help much — if at all — with the heralded secure boot.

    Secure boot is a hot topic. Upon startup, a device should run only the authorized code, not rogue software planted by a malicious actor. However, TPMs don’t provide secure boot. This occurs before the TPM comes into play. When a system powers on, early boot code (such as a UEFI BIOS) must decide which software will run next and which measurements are sent to the TPM. After the secure boot decisions are made, then the TPM can be used. The currently-running software can use the TPM to authenticate or decrypt the next piece of software before it loads, but this does not protect a system if an attacker can get at the early boot code.

    The TPM can support a well-designed boot process (including “measured boot” or “trusted boot,” which we will discuss later), but the TPM has no impact on a secure boot.

    Surprise 4: TPM has not been particularly successful considering how long it’s been available.

    TPM has withstood significant scrutiny and is well established in the security community. Given TPM’s favorable reputation, its longevity (more than 20 years and counting) and the fact that TPMs have shipped in volume in PCs since 2005, it’s surprising how few people really know how to work with them. As a result — especially in the IoT realm — TPMs are not being tapped to their full potential. TPMs became a ubiquitous checkoff item on RFPs for PC-related projects and appear in billions of devices today, but most devices use TPMs minimally, or not at all.

    The good news: TPM 2.0 is more flexible than the original TPM specification, allowing the newest TPMs to be applied to many embedded applications, including industrial sensors and smart home devices. Example: There is a TPM 2.0 profile for using TPM on limited-functionality ECUs for automotive applications. Now, designers and developers can more easily select granular TPM functions, whether for vehicles or a valve controller at a water utility.

    Surprise 5: Leveraging TPMs is exceedingly difficult. They were not designed to be user-friendly… and they’re not.

    It took the top companies in the PC industry — Compaq, HP, IBM, Intel, Microsoft and others — years to build the ecosystem needed to make implementation of TPMs for PCs feasible. These companies carved out the TPM space, driving updates to hardware, firmware and software and defining new protocols. The expectation (or at least hope) was that with this infrastructure, TPM would become an effective enabler, acting like an interstate highway for security. That is, they would provide a smooth, straight, easy way to get to the destination. Unfortunately, TPM turned out to be so complicated that even with this rich ecosystem, almost nobody built solutions to leverage it.

    Surprise 6: TPMs aren’t cheap.

    Keep in mind, TPMs are hardware. Then, remember they’re not just hardware. Implementing a TPM solution also entails software, the device’s physical design, re-architecture of the system and modifications to integrate with the broader infrastructure. Adding a TPM could increase the cost of a device by fifty cents or more. For many embedded applications, that added cost is a dealbreaker. For devices already being re-architected or that have high security requirements, like those used to operate and secure industrial sites or critical infrastructure, the incremental cost is more likely to be justifiable.

    Surprise 7: If a TPM is only used as a secure repository for encryption keys, money is probably being wasted.

    Despite having a range of capabilities, TPMs are often used solely to protect symmetric or asymmetric keys, but simpler hardware or software-based designs can often do that job just as well as a TPM. If your platform already has a TPM, by all means, use it for key protection, but if you have a TPM, why not take advantage of the TPM’s more powerful features such as measurement-based access control and remote attestation?

    Surprise 8: To retrofit an existing system, a hardware TPM is a non-starter.

    Forget about it. Here’s why: the TPM must be architected into the overall system from the beginning. It’s not a last-minute add-on to plug in once a device has been produced. It’s hardware, and the platform must physically accommodate it. Moreover, the TPM must be fully integrated into the boot process and security functions of the platform.

    Firmware or software-based TPMs offer alternatives. They are typically less secure than hardware-based TPM, but they can more easily be integrated into your design.

     

    Source: https://www.iotworldtoday.com/2019/02/07/trusted-platform-modules-8-surprises-for-iot-security/

  • Researchers unveil Internet of Things security feature

    ‘Physically unclonable function’ is 10 times more reliable than previous methods

    Rice University integrated circuit (IC) designers are at Silicon Valley’s premier chip-design conference to unveil technology that is 10 times more reliable than current methods of producing unclonable digital fingerprints for Internet of Things (IoT) devices.

    Rice’s Kaiyuan Yang and Dai Li will present their physically unclonable function (PUF) technology today at the 2019 International Solid-State Circuits Conference (ISSCC), a prestigious scientific conference known informally as the “Chip Olympics.” PUF uses a microchip’s physical imperfections to produce unique security keys that can be used to authenticate devices linked to the Internet of Things.

    Considering that some experts expect Earth to pass the threshold of 1 trillion internet-connected sensors within five years, there is growing pressure to improve the security of IoT devices.

    Yang and Li’s PUF provides a leap in reliability by generating two unique fingerprints for each PUF. This “zero-overhead” method uses the same PUF components to make both keys and does not require extra area and latency because of an innovative design feature that also allows their PUF to be about 15 times more energy efficient than previously published versions.

    “Basically each PUF unit can work in two modes,” said Yang, assistant professor of electrical and computer engineering. “In the first mode, it creates one fingerprint, and in the other mode it gives a second fingerprint. Each one is a unique identifier, and dual keys are much better for reliability. On the off chance the device fails in the first mode, it can use the second key. The probability that it will fail in both modes is extremely small.”

    As a means of authentication, PUF fingerprints have several of the same advantages as human fingerprints, he said.

    “First, they are unique,” Yang said. “You don’t have to worry about two people having the same fingerprint. Second, they are bonded to the individual. You cannot change your fingerprint or copy it to someone else’s finger. And finally, a fingerprint is unclonable. There’s no way to create a new person who has the same fingerprint as someone else.”

    PUF-derived encryption keys are also unique, bonded and unclonable. To understand why, it helps to understand that each transistor on a computer chip is incredibly small. More than a billion of them can be crammed onto a chip half the size of a credit card. But for all their precision, microchips are not perfect. The difference between transistors can amount to a few more atoms in one or a few less in another, but those miniscule differences are enough to produce the electronic fingerprints used to make PUF keys.

    For a 128-bit key, a PUF device would send request signals to an array of PUF cells comprising several hundred transistors, allocating a one or zero to each bit based on the responses from the PUF cells. Unlike a numeric key that’s stored in a traditional digital format, PUF keys are actively created each time they’re requested, and different keys can be used by activating a different set of transistors.

    Adopting PUF would allow chipmakers to inexpensively and securely generate secret keys for encryption as a standard feature on next-generation computer chips for IoT devices like “smart home” thermostats, security cameras and lightbulbs.

    Encrypted lightbulbs?

    If that sounds like overkill, consider that unsecured IoT devices are what three young computer savants assembled by the hundreds of thousands to mount the October 2016 distributed denial-of-service attack that crippled the internet on the East Coast for most of a day.

    “The general concept for IoT is to connect physical objects to the internet in order to integrate the physical and cyber worlds,” Yang said. “In most consumer IoT today, the concept isn’t fully realized because many of the devices are powered and almost all use existing IC feature sets that were developed for the mobile market.”

    In contrast, the devices coming out of research labs like Yang’s are designed for IoT from the ground up. Measuring just a few millimeters in size, the latest IoT prototypes can pack a processor, flash memory, wireless transmitter, antenna, one or more sensors, batteries and more into an area the size of a grain of rice.

    PUF is not a new idea for IoT security, but Yang and Li’s version of PUF is unique in terms of reliability, energy efficiency and the amount of area it would take to implement on a chip. For starters, Yang said the performance gains were measured in tests at military-grade temperatures ranging from 125 degrees Celsius to minus 55 degrees Celsius and when supply voltage dropped by up to 50 percent.

    “If even one transistor behaves abnormally under varying environmental conditions, the device will produce the wrong key, and it will look like an inauthentic device,” Yang said. “For that reason, reliability, or stability, is the most important measure for PUF.”

    Energy efficiency also is important for IoT, where devices can be expected to run for a decade on a single battery charge. In Yang and Li’s PUF, keys are created using a static voltage rather than by actively powering up the transistor. It’s counterintuitive that the static approach would be more energy efficient because it’s the equivalent of leaving the lights on 24/7 rather than flicking the switch to get a quick glance of the room.

    “Normally, people have sleep mode activated, and when they want to create a key, they activate the transistor, switch it once and then put it to sleep again,” Yang said. “In our design, the PUF module is always on, but it takes very little power, even less than a conventional system in sleep mode.”

    On-chip area — the amount of space and expense manufacturers would have to allocate to put the PUF device on a production chip — is the third metric where they outperform previously reported work. Their design occupied 2.37 square micrometers to generate one bit on prototypes produced using 65-nanometer complementary metal-oxide-semiconductor (CMOS) technology.

    The research was funded by Rice University.

     

    Source: http://news.rice.edu/2019/02/20/rice-u-researchers-unveil-internet-of-things-security-feature/