SRAM security concerns are intensifying as a combination of new and existing techniques allow hackers to tap into data for longer periods of time after a device is powered down.

This is particularly alarming as the leading edge of design shifts from planar SoCs to heterogeneous systems in package, such as those used in AI or edge processing, where chiplets frequently have their own memory hierarchy. Until now, most cybersecurity concerns involving volatile memory have focused on DRAM, because it is often external and easier to attack. SRAM, in contrast, does not contain a component as obviously vulnerable as a heat-sensitive capacitor, and in the past it has been harder to pinpoint. But as SoCs are disaggregated and more features are added into devices, SRAM is becoming a much bigger security concern.

The attack scheme is well understood. Known as cold boot, it was first identified in 2008, and is essentially a variant of a side-channel attack. In a cold boot approach, an attacker dumps data from internal SRAM to an external device, and then restarts the system from the external device with some code modification. “Cold boot is primarily targeted at SRAM, with the two primary defenses being isolation and in-memory encryption,” said Vijay Seshadri, distinguished engineer at Cycuity.

Compared with network-based attacks, such as DRAM’s rowhammer, cold boot is relatively simple. It relies on physical proximity and a can of compressed air.

The vulnerability was first described by Edward Felton, director of Princeton University’s Center for Information Technology Policy, J. Alex Halderman, currently director of the Center for Computer Security & Society at the University of Michigan, and colleagues. The breakthrough in their research was based on the growing realization in the engineering research community that data does not vanish from memory the moment a device is turned off, which until then was a common assumption. Instead, data in both DRAM and SRAM has a brief “remanence.”[1]

Using a cold boot approach, data can be retrieved, especially if an attacker sprays the chip with compressed air, cooling it enough to slow the degradation of the data. As the researchers described their approach, “We obtained surface temperatures of approximately −50°C with a simple cooling technique — discharging inverted cans of ‘canned air’ duster spray directly onto the chips. At these temperatures, we typically found that fewer than 1% of bits decayed even after 10 minutes without power.”

Unfortunately, despite nearly 20 years of security research since the publication of the Halderman paper, the authors’ warning still holds true. “Though we discuss several strategies for mitigating these risks, we know of no simple remedy that would eliminate them.”

However unrealistic, there is one simple and obvious remedy to cold boot — never leave a device unattended. But given human behavior, it’s safer to assume that every device is vulnerable, from smart watches to servers, as well as automotive chips used for increasingly autonomous driving.

While the original research exclusively examined DRAM, within the last six years cold boot has proven to be one of the most serious vulnerabilities for SRAM. In 2018, researchers at Germany’s Technische Universität Darmstadt published a paper describing a cold boot attack method that is highly resistant to memory erasure techniques, and which can be used to manipulate the cryptographic keys produced by the SRAM physical unclonable function (PUF).

As with so many security issues, it’s been a cat-and-mouse game between remedies and counter-attacks. And because cold boot takes advantage of slowing down memory degradation, in 2022 Yang-Kyu Choi and colleagues at the Korea Advanced Institute of Science and Technology (KAIST), described a way to undo the slowdown with an ultra-fast data sanitization method that worked within 5 ns, using back bias to control the device parameters of CMOS.

Fig. 1: Asymmetric forward back-biasing scheme for permanent erasing. (a) All the data are reset to 1. (b) All the data are reset to 0. Whether all the data where reset to 1 or 0 is determined by the asymmetric forward back-biasing scheme. Source: KAIST/Creative Commons [2]

Their paper, as well as others, have inspired new approaches to combating cold boot attacks.

“To mitigate the risk of unauthorized access from unknown devices, main devices, or servers, check the authenticated code and unique identity of each accessing device,” said Jongsin Yun, memory technologist at Siemens EDA. “SRAM PUF is one of the ways to securely identify each device. SRAM is made of two inverters cross-coupled to each other. Although each inverter is designed to be the same device, normally one part of the inverter has a somewhat stronger NMOS than the other due to inherent random dopant fluctuation. During the initial power-on process, SRAM data will be either data 1 or 0, depending on which side has a stronger device. In other words, the initial data state of the SRAM array at the power on is decided by this unique random process variation and most of the bits maintain this property for life. One can use this unique pattern as a fingerprint of a device. The SRAM PUF data is reconstructed with other coded data to form a cryptographic key. SRAM PUF is a great way to anchor its secure data into hardware. Hackers may use a DFT circuit to access the memory. To avoid insecurely reading the SRAM information through DFT, the security-critical design makes DFT force delete the data as an initial process of TEST mode.”

However, there can be instances where data may be required to be kept in a non-volatile memory (NVM). “Data is considered insecure if the NVM is located outside of the device,” said Yun. “Therefore, secured data needs to be stored within the device with write protection. One-time programmable (OTP) memory or fuses are good storage options to prevent malicious attackers from tampering with the modified information. OTP memory and fuses are used to store cryptographic keys, authentication information, and other critical settings for operation within the device. It is useful for anti-rollback, which prevents hackers from exploiting old vulnerabilities that have been fixed in newer versions.”

Chiplet vulnerabilities
Chiplets also could present another vector for attack, due to their complexity and interconnections. “A chiplet has memory, so it’s going to be attacked,” said Cycuity’s Seshadri. “Chiplets, in general, are going to exacerbate the problem, rather than keeping it status quo, because you’re going to have one chiplet talking to another. Could an attack on one chiplet have a side effect on another? There need to be standards to address this. In fact, they’re coming into play already. A chiplet provider has to say, ‘Here’s what I’ve done for security. Here’s what needs to be done when interfacing with another chiplet.”

Yun notes there is a further physical vulnerability for those working with chiplets and SiPs. “When multiple chiplets are connected to form a SiP, we have to trust data coming from an external chip, which creates further complications. Verification of the chiplet’s authenticity becomes very important for SiPs, as there is a risk of malicious counterfeit chiplets being connected to the package for hacking purposes. Detection of such counterfeit chiplets is imperative.”

These precautions also apply when working with DRAM. In all situations, Seshardi said, thinking about security has to go beyond device-level protection. “The onus of protecting DRAM is not just on the DRAM designer or the memory designer,” he said. “It has to be secured by design principles when you are developing. In addition, you have to look at this holistically and do it at a system level. You must consider all the other things that communicate with DRAM or that are placed near DRAM. You must look at a holistic solution, all the way from software down to things like the memory controller and then finally, the DRAM itself.”

Encryption as a backup
Data itself always must be encrypted as second layer of protection against known and novel attacks, so an organization’s assets will still be protected even if someone breaks in via cold boot or another method.

“The first and primary method of preventing a cold boot attack is limiting physical access to the systems, or physically modifying the systems case or hardware preventing an attacker’s access,” said Jim Montgomery, market development director, semiconductor at TXOne Networks. “The most effective programmatic defense against an attack is to ensure encryption of memory using either a hardware- or software-based approach. Utilizing memory encryption will ensure that regardless of trying to dump the memory, or physically removing the memory, the encryption keys will remain secure.”

Montgomery also points out that TXOne is working with the Semiconductor Manufacturing Cybersecurity Consortium (SMCC) to develop common criteria based upon SEMI E187 and E188 standards to assist DM’s and OEM’s to implement secure procedures for systems security and integrity, including controlling the physical environment.

What kind and how much encryption will depend on use cases, said Jun Kawaguchi, global marketing executive for Winbond. “Encryption strength for a traffic signal controller is going to be different from encryption for nuclear plants or medical devices, critical applications where you need much higher levels,” he said. “There are different strengths and costs to it.”

Another problem, in the post-quantum era, is that encryption itself may be vulnerable. To defend against those possibilities, researchers are developing post-quantum encryption schemes. One way to stay a step ahead is homomorphic encryption [HE], which will find a role in data sharing, since computations can be performed on encrypted data without first having to decrypt it.

Homomorphic encryption could be in widespread use as soon as the next few years, according to Ronen Levy, senior manager for IBM’s Cloud Security & Privacy Technologies Department, and Omri Soceanu, AI Security Group manager at IBM.  However, there are still challenges to be overcome.

“There are three main inhibitors for widespread adoption of homomorphic encryption — performance, consumability, and standardization,” according to Levy. “The main inhibitor, by far, is performance. Homomorphic encryption comes with some latency and storage overheads. FHE hardware acceleration will be critical to solving these issues, as well as algorithmic and cryptographic solutions, but without the necessary expertise it can be quite challenging.”

An additional issue is that most consumers of HE technology, such as data scientists and application developers, do not possess deep cryptographic skills, HE solutions that are designed for cryptographers can be impractical. A few HE solutions require algorithmic and cryptographic expertise that inhibit adoption by those who lack these skills.

Finally, there is a lack of standardization. “Homomorphic encryption is in the process of being standardized,” said Soceanu. “But until it is fully standardized, large organizations may be hesitant to adopt a cryptographic solution that has not been approved by standardization bodies.”

Once these issues are resolved, they predicted widespread use as soon as the next few years. “Performance is already practical for a variety of use cases, and as hardware solutions for homomorphic encryption become a reality, more use cases would become practical,” said Levy. “Consumability is addressed by creating more solutions, making it easier and hopefully as frictionless as possible to move analytics to homomorphic encryption. Additionally, standardization efforts are already in progress.”

A new attack and an old problem
Unfortunately, security never will be as simple as making users more aware of their surroundings. Otherwise, cold boot could be completely eliminated as a threat. Instead, it’s essential to keep up with conference talks and the published literature, as graduate students keep probing SRAM for vulnerabilities, hopefully one step ahead of genuine attackers.

For example, SRAM-related cold boot attacks originally targeted discrete SRAM. The reason is that it’s far more complicated to attack on-chip SRAM, which is isolated from external probing and has minimal intrinsic capacitance. However, in 2022, Jubayer Mahmod, then a graduate student at Virginia Tech and his advisor, associate professor Matthew Hicks, demonstrated what they dubbed “Volt Boot,” a new method that could penetrate on-chip SRAM. According to their paper, “Volt Boot leverages asymmetrical power states (e.g., on vs. off) to force SRAM state retention across power cycles, eliminating the need for traditional cold boot attack enablers, such as low-temperature or intrinsic data retention time…Unlike other forms of SRAM data retention attacks, Volt Boot retrieves data with 100% accuracy — without any complex post-processing.”

Conclusion
While scientists and engineers continue to identify vulnerabilities and develop security solutions, decisions about how much security to include in a design is an economic one. Cost vs. risk is a complex formula that depends on the end application, the impact of a breach, and the likelihood that an attack will occur.

“It’s like insurance,” said Kawaguchi. “Security engineers and people like us who are trying to promote security solutions get frustrated because, similar to insurance pitches, people respond with skepticism. ‘Why would I need it? That problem has never happened before.’ Engineers have a hard time convincing their managers to spend that extra dollar on the costs because of this ‘it-never-happened-before’ attitude. In the end, there are compromises. Yet ultimately, it’s going to cost manufacturers a lot of money when suddenly there’s a deluge of demands to fix this situation right away.”

References

1. S. Skorobogatov, “Low temperature data remanence in static RAM”, Technical report UCAM-CL-TR-536, University of Cambridge Computer Laboratory, June 2002.
2. Han, SJ., Han, JK., Yun, GJ. et al. Ultra-fast data sanitization of SRAM by back-biasing to resist a cold boot attack. Sci Rep 12, 35 (2022). https://doi.org/10.1038/s41598-021-03994-2

The post SRAM Security Concerns Grow appeared first on Semiconductor Engineering.

Machine learning is being used by hackers to find weaknesses in chips and systems, but it also is starting to be used to prevent breaches by pinpointing hardware and software design flaws.

To make this work, machine learning (ML) must be trained to identify vulnerabilities, both in hardware and software. With proper training, ML can detect cyber threats and prevent them from accessing critical data. As ML encounters additional cyberattack scenarios, it can learn and adapt, helping to build a more sophisticated defense system that includes hardware, software, and how they interface with larger systems. It also can automate many cyber defense tasks with minimum human intervention, which saves time, effort, and money.

ML is capable of sifting through large volumes of data much faster than humans. Potentially, it can reduce or remove human errors, lower costs, and boost cyber defense capability and overall efficiency. It also can perform such tasks as connection authentication, system design, vulnerability detection, and most important, threat detection through pattern and behavioral analysis.

“AI/ML is finding many roles protecting and enhancing security for digital devices and services,” said David Maidment, senior director of market development at Arm. “However, it is also being used as a tool for increasingly sophisticated attacks by threat actors. AI/ML is essentially a tool tuned for very advanced pattern recognition across vast data sets. Examples of how AI/ML can enhance security include network-based monitoring to spot rogue behaviors at scale, code analysis to look for vulnerabilities on new and legacy software, and automating the deployment of software to keep devices up-to-date and secure.”

This means that while AI/ML can be used as a force for good, inevitably bad actors will use it to increase the sophistication and scale of attacks. “Building devices and services based on security best practices, having a hardware-protected root of trust (RoT), and an industry-wide methodology to standardize and measure security are all essential,” Maidment said. “The focus on security, including the rapid growth of AI/ML, is certainly driving industry and government discussions as we work on solutions to maximize AI/ML’s benefits and minimize any potential harmful impact.”

Zero trust is a fundamental requirement when it comes to cybersecurity. Before a user or device is allowed to connect to the network or server, requests have to be authenticated to make sure they are legitimate and authorized. ML will enhance the authentication process, including password management, phishing prevention, and malware detection.

Areas that bad actors look to exploit are software design vulnerabilities and weak points in systems and networks. Once hackers uncover these vulnerabilities, they can be used as a point of entrance to the network or systems. ML can detect these vulnerabilities and alert administrators.

Taking a proactive approach by doing threat detection is essential in cyber defense. ML pattern and behavioral analysis strengths support this strategy. When ML detects unusual behavior in data traffic flow or patterns, it sends an alert about abnormal behavior to the administrator. This is similar to the banking industry’s practice of watching for credit card use that does not follow an established pattern. A large purchase overseas on a credit card with a pattern of U.S. use only for moderate amounts would trigger an alert, for example.

As hackers become more sophisticated with new attack vectors, whether it is new ransomware or distributed denial of service (DDoS) attacks, ML will do a much better job than humans in detecting these unknown threats.

Limitations of ML in cybersecurity
While ML provides many benefits, its value depends on the data used to train it. The more that can be used to train the ML model, the better it is at detecting fraud and cyber threats. But acquiring this data raises overall cybersecurity system design expenses. The model also needs constant maintenance and tuning to sustain peak performance and meet the specific needs of users. And while ML can do many of the tasks, it still requires some human involvement, so it’s essential to understand both cybersecurity and how well ML functions.

While ML is effective in fending off many of the cyberattacks, it is not a panacea. “The specific type of artificial intelligence typically referenced in this context is machine learning (ML), which is the development of algorithms that can ingest large volumes of training data, then generalize and make meaningful observations and decisions based on novel data,” said Scott Register, vice president of security solutions at Keysight Technologies. “With the right algorithms and training, AI/ML can be used to pinpoint cyberattacks which might otherwise be difficult to detect.”

However, no one — at least in the commercial space — has delivered a product that can detect very subtle cyberattacks with complete accuracy. “The algorithms are getting better all the time, so it’s highly probable that we’ll soon have commercial products that can detect and respond to attacks,” Register said. “We must keep in mind, however, that attackers don’t sit still, and they’re well-funded and patient. They employ ‘offensive AI,’ which means they use the same types of techniques and algorithms to generate attacks which are unlikely to be detected.”

ML implementation considerations
For any ML implementation, a strong cyber defense system is essential, but there’s no such thing as a completely secure design. Instead, security is a dynamic and ongoing process that requires constant fine-tuning and improvement against ever-changing cyberattacks. Implementing ML requires a clear security roadmap, which should define requirements. It also requires implementing a good cybersecurity process, which secures individual hardware and software components, as well as some type of system testing.

“One of the things we advise is to start with threat modeling to identify a set of critical design assets to protect from an adversary under confidentiality or integrity,” said Jason Oberg, CTO at Cycuity. “From there, you can define a set of very succinct, secure requirements for the assets. All of this work is typically done at the architecture level. We do provide education, training and guidance to our customers, because at that level, if you don’t have succinct security requirements defined, then it’s really hard to verify or check something in the design. What often happens is customers will say, ‘I want to have a secure chip.’ But it’s not as easy as just pressing a button and getting a green check mark that confirms the chip is now secure.”

To be successful, engineering teams must start at the architectural stages and define the security requirements. “Once that is done, they can start actually writing the RTL,” Oberg said. “There are tools available to provide assurances these security requirements are being met, and run within the existing simulation and emulation environments to help validate the security requirements, and help identify any unknown design weaknesses. Generally, this helps hardware and verification engineers increase their productivity and build confidence that the system is indeed meeting the security requirements.”

Fig. 1: A cybersecurity model includes multiple stages, progressing from the very basic to in-depth. It is important for organizations to know what stages their cyber defense system are. Source: Cycuity

Steve Garrison, senior vice president, marketing of Stellar Cyber, noted that if cyber threats were uncovered during the detection process, so many data files may be generated that they will be difficult for humans to sort through. Graphical displays can speed up the process and reduce the overall mean time to detection (MTTD) and mean time to response (MTTR).

Fig. 2: Using graphical displays  would reduce the overall meantime to detection (MTTD) and meantime to response (MTTR). Source: Stellar Cyber

Testing is essential
Another important stage in the design process is testing, whereby each system design requires a vigorous attack simulation tool to weed out the basic oversights to ensure it meets the predefined standard.

“First, if you want to understand how defensive systems will function in the real world, it’s important to test them under conditions, which are as realistic as possible,” Keysight’s Register said. “The network environment should have the same amount of traffic, mix of applications, speeds, behavioral characteristics, and timing as the real world. For example, the timing of a sudden uptick in email and social media traffic corresponds to the time when people open up their laptops at work. The attack traffic needs to be as realistic as possible as well – hackers try hard not to be noticed, often preferring ‘low and slow’ attacks, which may take hours or days to complete, making detection much more difficult. The same obfuscation techniques, encryption, and decoy traffic employed by threat actors needs to be simulated as accurately as possible.”

Further, due to mistaken assumptions during testing, defensive systems often perform great in the lab, yet fail spectacularly in production networks.  “Afterwards we hear, for example, ‘I didn’t think hackers would encrypt their malware,’ or ‘Internal e-mails weren’t checked for malicious attachments, only those from external senders,’” Register explained. “Also, in security testing, currency is key. Attacks and obfuscation techniques are constantly evolving. If a security system is tested against stale attacks, then the value of that testing is limited. The offensive tools should be kept as up to date as possible to ensure the most effective performance against the tools a system is likely to encounter in the wild.”

Semiconductor security
Almost all system designs depend on semiconductors, so it is important to ensure that any and all chips, firmware, FPGAs, and SoCs are secure – including those that perform ML functionality.

“Semiconductor security is a constantly evolving problem and requires an adaptable solution, said Jayson Bethurem, vice president marketing and business development at Flex Logix. “Fixed solutions with current cryptography that are implemented today will inevitably be challenged in the future. Hackers today have more time, resources, training, and motivation to disrupt technology. With technology increasing in every facet of our lives, defending against this presents a real challenge. We also have to consider upcoming threats, namely quantum computing.”

Many predict that quantum computing will be able to crack current cryptography solutions in the next few years. “Fortunately, semiconductor manufacturers have solutions that can enable cryptography agility, which can dynamically adapt to evolving threats,” Bethurem said. “This includes both updating hardware accelerated cryptography algorithms and obfuscating them, an approach that increases root of trust and protects valuable IP secrets. Advanced solutions like these also involve devices randomly creating their own encryption keys, making it harder for algorithms to crack encryption codes.”

Advances in AI/ML algorithms can adapt to new threats and reduce latency of algorithm updates from manufacturers. This is particularly useful with reconfigurable eFPGA IP, which can be implemented into any semiconductor device to thwart all current and future threats and optimized to run AI/ML-based cryptography solutions. The result is a combination of high-performance processing, scalability, and low-latency attack response.

Chips that support AI/ML algorithms need not only computing power, but also accelerators for those algorithms. In addition, all of this needs to happen without exceeding a tight power budget.

“More AI/ML systems run at tiny edges rather than at the core,” said Detlef Houdeau, senior director of design system architecture at Infineon Technologies. “AI/ML systems don’t need any bigger computer and/or cloud. For instance, a Raspberry Pi for a robot in production can have more than 3 AI/ML algorithms working in parallel. A smartphone has more than 10 AI/ML functions in the phone, and downloading new apps brings new AI/ML algorithms into the device. A pacemaker can have 2 AI/ML algorithms. Security chips, meanwhile, need a security architecture as well as accelerators for encryption. Combining an AI/ML accelerator with an encryption accelerator in the same chip could increase the performance in microcontroller units, and at the same time foster more security at the edge. The next generation of microelectronics could show this combination.”

After developers have gone through design reviews and the systems have run vigorous tests, it helps to have third-party certification and/or credentials to ensure the systems are indeed secure from a third-party independent viewpoint.

“As AI, and recently generative AI, continue to transform all markets, there will be new attack vectors to mitigate against,” said Arm’s Maidment. “We expect to see networks become smarter in the way they monitor traffic and behaviors. The use of AI/ML allows network-based monitoring at scale to allow potential unexpected or rogue behavior to be identified and isolated. Automating network monitoring based on AI/ML will allow an extra layer of defense as networks scale out and establish effectively a ‘zero trust’ approach. With this approach, analysis at scale can be tuned to look at particular threat vectors depending on the use case.”

With an increase in AI/ML adoption at the edge, a lot of this is taking place on the CPU. “Whether it is handling workloads in their entirety, or in combination with a co-processor like a GPU or NPU, how applications are deployed across the compute resources needs to be secure and managed centrally within the edge AI/ML device,” Maidment said. “Building edge AI/ML devices based on a hardware root of trust is essential. It is critical to have privileged access control of what code is allowed to run where using a trusted memory management architecture. Arm continually invests in security, and the Armv9 architecture offers a number of new security features. Alongside architecture improvements, we continue to work in partnership with the industry on our ecosystem security framework and certification scheme, PSA Certified, which is based on a certified hardware RoT. This hardware base helps to improve the security of systems and fulfill the consumer expectation that as devices scale, they remain secure.”

Outlook
It is important to understand that threat actors will continue to evolve attacks using AI/ML. Experts suggest that to counter such attacks, organizations, institutions, and government agencies will have to continually improve defense strategies and capabilities, including AI/ML deployment.

AI/ML can be used as weapon from an attacker for industrial espionage and/or industrial sabotage, and stopping incursions will require a broad range of cyberattack prevention and detection tools, including AI/ML functionality for anomaly detection. But in general, hackers are almost always one step ahead.

According to Register, “the recurring cycle is: 1) hackers come out with a new tool or technology that lets them attack systems or evade detection more effectively; 2) those attacks cause enough economic damage that the industry responds and develops effective countermeasures; 3) the no-longer-new hacker tools are still employed effectively, but against targets that haven’t bothered to update their defenses; 4) hackers develop new offensive tools that are effective against the defensive techniques of high-value targets, and the cycle starts anew.”

Related Reading
Securing Chip Manufacturing Against Growing Cyber Threats
Suppliers are the number one risk, but reducing attacks requires industry-wide collaboration.
Data Center Security Issues Widen
The number and breadth of hardware targets is increasing, but older attack vectors are not going away. Hackers are becoming more sophisticated, and they have a big advantage.

The post Using AI/ML To Combat Cyberattacks appeared first on Semiconductor Engineering.

SRAM security concerns are intensifying as a combination of new and existing techniques allow hackers to tap into data for longer periods of time after a device is powered down.

This is particularly alarming as the leading edge of design shifts from planar SoCs to heterogeneous systems in package, such as those used in AI or edge processing, where chiplets frequently have their own memory hierarchy. Until now, most cybersecurity concerns involving volatile memory have focused on DRAM, because it is often external and easier to attack. SRAM, in contrast, does not contain a component as obviously vulnerable as a heat-sensitive capacitor, and in the past it has been harder to pinpoint. But as SoCs are disaggregated and more features are added into devices, SRAM is becoming a much bigger security concern.

The attack scheme is well understood. Known as cold boot, it was first identified in 2008, and is essentially a variant of a side-channel attack. In a cold boot approach, an attacker dumps data from internal SRAM to an external device, and then restarts the system from the external device with some code modification. “Cold boot is primarily targeted at SRAM, with the two primary defenses being isolation and in-memory encryption,” said Vijay Seshadri, distinguished engineer at Cycuity.

Compared with network-based attacks, such as DRAM’s rowhammer, cold boot is relatively simple. It relies on physical proximity and a can of compressed air.

The vulnerability was first described by Edward Felton, director of Princeton University’s Center for Information Technology Policy, J. Alex Halderman, currently director of the Center for Computer Security & Society at the University of Michigan, and colleagues. The breakthrough in their research was based on the growing realization in the engineering research community that data does not vanish from memory the moment a device is turned off, which until then was a common assumption. Instead, data in both DRAM and SRAM has a brief “remanence.”[1]

Using a cold boot approach, data can be retrieved, especially if an attacker sprays the chip with compressed air, cooling it enough to slow the degradation of the data. As the researchers described their approach, “We obtained surface temperatures of approximately −50°C with a simple cooling technique — discharging inverted cans of ‘canned air’ duster spray directly onto the chips. At these temperatures, we typically found that fewer than 1% of bits decayed even after 10 minutes without power.”

Unfortunately, despite nearly 20 years of security research since the publication of the Halderman paper, the authors’ warning still holds true. “Though we discuss several strategies for mitigating these risks, we know of no simple remedy that would eliminate them.”

However unrealistic, there is one simple and obvious remedy to cold boot — never leave a device unattended. But given human behavior, it’s safer to assume that every device is vulnerable, from smart watches to servers, as well as automotive chips used for increasingly autonomous driving.

While the original research exclusively examined DRAM, within the last six years cold boot has proven to be one of the most serious vulnerabilities for SRAM. In 2018, researchers at Germany’s Technische Universität Darmstadt published a paper describing a cold boot attack method that is highly resistant to memory erasure techniques, and which can be used to manipulate the cryptographic keys produced by the SRAM physical unclonable function (PUF).

As with so many security issues, it’s been a cat-and-mouse game between remedies and counter-attacks. And because cold boot takes advantage of slowing down memory degradation, in 2022 Yang-Kyu Choi and colleagues at the Korea Advanced Institute of Science and Technology (KAIST), described a way to undo the slowdown with an ultra-fast data sanitization method that worked within 5 ns, using back bias to control the device parameters of CMOS.

Fig. 1: Asymmetric forward back-biasing scheme for permanent erasing. (a) All the data are reset to 1. (b) All the data are reset to 0. Whether all the data where reset to 1 or 0 is determined by the asymmetric forward back-biasing scheme. Source: KAIST/Creative Commons [2]

Their paper, as well as others, have inspired new approaches to combating cold boot attacks.

“To mitigate the risk of unauthorized access from unknown devices, main devices, or servers, check the authenticated code and unique identity of each accessing device,” said Jongsin Yun, memory technologist at Siemens EDA. “SRAM PUF is one of the ways to securely identify each device. SRAM is made of two inverters cross-coupled to each other. Although each inverter is designed to be the same device, normally one part of the inverter has a somewhat stronger NMOS than the other due to inherent random dopant fluctuation. During the initial power-on process, SRAM data will be either data 1 or 0, depending on which side has a stronger device. In other words, the initial data state of the SRAM array at the power on is decided by this unique random process variation and most of the bits maintain this property for life. One can use this unique pattern as a fingerprint of a device. The SRAM PUF data is reconstructed with other coded data to form a cryptographic key. SRAM PUF is a great way to anchor its secure data into hardware. Hackers may use a DFT circuit to access the memory. To avoid insecurely reading the SRAM information through DFT, the security-critical design makes DFT force delete the data as an initial process of TEST mode.”

However, there can be instances where data may be required to be kept in a non-volatile memory (NVM). “Data is considered insecure if the NVM is located outside of the device,” said Yun. “Therefore, secured data needs to be stored within the device with write protection. One-time programmable (OTP) memory or fuses are good storage options to prevent malicious attackers from tampering with the modified information. OTP memory and fuses are used to store cryptographic keys, authentication information, and other critical settings for operation within the device. It is useful for anti-rollback, which prevents hackers from exploiting old vulnerabilities that have been fixed in newer versions.”

Chiplet vulnerabilities
Chiplets also could present another vector for attack, due to their complexity and interconnections. “A chiplet has memory, so it’s going to be attacked,” said Cycuity’s Seshadri. “Chiplets, in general, are going to exacerbate the problem, rather than keeping it status quo, because you’re going to have one chiplet talking to another. Could an attack on one chiplet have a side effect on another? There need to be standards to address this. In fact, they’re coming into play already. A chiplet provider has to say, ‘Here’s what I’ve done for security. Here’s what needs to be done when interfacing with another chiplet.”

Yun notes there is a further physical vulnerability for those working with chiplets and SiPs. “When multiple chiplets are connected to form a SiP, we have to trust data coming from an external chip, which creates further complications. Verification of the chiplet’s authenticity becomes very important for SiPs, as there is a risk of malicious counterfeit chiplets being connected to the package for hacking purposes. Detection of such counterfeit chiplets is imperative.”

These precautions also apply when working with DRAM. In all situations, Seshardi said, thinking about security has to go beyond device-level protection. “The onus of protecting DRAM is not just on the DRAM designer or the memory designer,” he said. “It has to be secured by design principles when you are developing. In addition, you have to look at this holistically and do it at a system level. You must consider all the other things that communicate with DRAM or that are placed near DRAM. You must look at a holistic solution, all the way from software down to things like the memory controller and then finally, the DRAM itself.”

Encryption as a backup
Data itself always must be encrypted as second layer of protection against known and novel attacks, so an organization’s assets will still be protected even if someone breaks in via cold boot or another method.

“The first and primary method of preventing a cold boot attack is limiting physical access to the systems, or physically modifying the systems case or hardware preventing an attacker’s access,” said Jim Montgomery, market development director, semiconductor at TXOne Networks. “The most effective programmatic defense against an attack is to ensure encryption of memory using either a hardware- or software-based approach. Utilizing memory encryption will ensure that regardless of trying to dump the memory, or physically removing the memory, the encryption keys will remain secure.”

Montgomery also points out that TXOne is working with the Semiconductor Manufacturing Cybersecurity Consortium (SMCC) to develop common criteria based upon SEMI E187 and E188 standards to assist DM’s and OEM’s to implement secure procedures for systems security and integrity, including controlling the physical environment.

What kind and how much encryption will depend on use cases, said Jun Kawaguchi, global marketing executive for Winbond. “Encryption strength for a traffic signal controller is going to be different from encryption for nuclear plants or medical devices, critical applications where you need much higher levels,” he said. “There are different strengths and costs to it.”

Another problem, in the post-quantum era, is that encryption itself may be vulnerable. To defend against those possibilities, researchers are developing post-quantum encryption schemes. One way to stay a step ahead is homomorphic encryption [HE], which will find a role in data sharing, since computations can be performed on encrypted data without first having to decrypt it.

Homomorphic encryption could be in widespread use as soon as the next few years, according to Ronen Levy, senior manager for IBM’s Cloud Security & Privacy Technologies Department, and Omri Soceanu, AI Security Group manager at IBM.  However, there are still challenges to be overcome.

“There are three main inhibitors for widespread adoption of homomorphic encryption — performance, consumability, and standardization,” according to Levy. “The main inhibitor, by far, is performance. Homomorphic encryption comes with some latency and storage overheads. FHE hardware acceleration will be critical to solving these issues, as well as algorithmic and cryptographic solutions, but without the necessary expertise it can be quite challenging.”

An additional issue is that most consumers of HE technology, such as data scientists and application developers, do not possess deep cryptographic skills, HE solutions that are designed for cryptographers can be impractical. A few HE solutions require algorithmic and cryptographic expertise that inhibit adoption by those who lack these skills.

Finally, there is a lack of standardization. “Homomorphic encryption is in the process of being standardized,” said Soceanu. “But until it is fully standardized, large organizations may be hesitant to adopt a cryptographic solution that has not been approved by standardization bodies.”

Once these issues are resolved, they predicted widespread use as soon as the next few years. “Performance is already practical for a variety of use cases, and as hardware solutions for homomorphic encryption become a reality, more use cases would become practical,” said Levy. “Consumability is addressed by creating more solutions, making it easier and hopefully as frictionless as possible to move analytics to homomorphic encryption. Additionally, standardization efforts are already in progress.”

A new attack and an old problem
Unfortunately, security never will be as simple as making users more aware of their surroundings. Otherwise, cold boot could be completely eliminated as a threat. Instead, it’s essential to keep up with conference talks and the published literature, as graduate students keep probing SRAM for vulnerabilities, hopefully one step ahead of genuine attackers.

For example, SRAM-related cold boot attacks originally targeted discrete SRAM. The reason is that it’s far more complicated to attack on-chip SRAM, which is isolated from external probing and has minimal intrinsic capacitance. However, in 2022, Jubayer Mahmod, then a graduate student at Virginia Tech and his advisor, associate professor Matthew Hicks, demonstrated what they dubbed “Volt Boot,” a new method that could penetrate on-chip SRAM. According to their paper, “Volt Boot leverages asymmetrical power states (e.g., on vs. off) to force SRAM state retention across power cycles, eliminating the need for traditional cold boot attack enablers, such as low-temperature or intrinsic data retention time…Unlike other forms of SRAM data retention attacks, Volt Boot retrieves data with 100% accuracy — without any complex post-processing.”

Conclusion
While scientists and engineers continue to identify vulnerabilities and develop security solutions, decisions about how much security to include in a design is an economic one. Cost vs. risk is a complex formula that depends on the end application, the impact of a breach, and the likelihood that an attack will occur.

“It’s like insurance,” said Kawaguchi. “Security engineers and people like us who are trying to promote security solutions get frustrated because, similar to insurance pitches, people respond with skepticism. ‘Why would I need it? That problem has never happened before.’ Engineers have a hard time convincing their managers to spend that extra dollar on the costs because of this ‘it-never-happened-before’ attitude. In the end, there are compromises. Yet ultimately, it’s going to cost manufacturers a lot of money when suddenly there’s a deluge of demands to fix this situation right away.”

References

1. S. Skorobogatov, “Low temperature data remanence in static RAM”, Technical report UCAM-CL-TR-536, University of Cambridge Computer Laboratory, June 2002.
2. Han, SJ., Han, JK., Yun, GJ. et al. Ultra-fast data sanitization of SRAM by back-biasing to resist a cold boot attack. Sci Rep 12, 35 (2022). https://doi.org/10.1038/s41598-021-03994-2

The post SRAM Security Concerns Grow appeared first on Semiconductor Engineering.

Machine learning is being used by hackers to find weaknesses in chips and systems, but it also is starting to be used to prevent breaches by pinpointing hardware and software design flaws.

To make this work, machine learning (ML) must be trained to identify vulnerabilities, both in hardware and software. With proper training, ML can detect cyber threats and prevent them from accessing critical data. As ML encounters additional cyberattack scenarios, it can learn and adapt, helping to build a more sophisticated defense system that includes hardware, software, and how they interface with larger systems. It also can automate many cyber defense tasks with minimum human intervention, which saves time, effort, and money.

ML is capable of sifting through large volumes of data much faster than humans. Potentially, it can reduce or remove human errors, lower costs, and boost cyber defense capability and overall efficiency. It also can perform such tasks as connection authentication, system design, vulnerability detection, and most important, threat detection through pattern and behavioral analysis.

“AI/ML is finding many roles protecting and enhancing security for digital devices and services,” said David Maidment, senior director of market development at Arm. “However, it is also being used as a tool for increasingly sophisticated attacks by threat actors. AI/ML is essentially a tool tuned for very advanced pattern recognition across vast data sets. Examples of how AI/ML can enhance security include network-based monitoring to spot rogue behaviors at scale, code analysis to look for vulnerabilities on new and legacy software, and automating the deployment of software to keep devices up-to-date and secure.”

This means that while AI/ML can be used as a force for good, inevitably bad actors will use it to increase the sophistication and scale of attacks. “Building devices and services based on security best practices, having a hardware-protected root of trust (RoT), and an industry-wide methodology to standardize and measure security are all essential,” Maidment said. “The focus on security, including the rapid growth of AI/ML, is certainly driving industry and government discussions as we work on solutions to maximize AI/ML’s benefits and minimize any potential harmful impact.”

Zero trust is a fundamental requirement when it comes to cybersecurity. Before a user or device is allowed to connect to the network or server, requests have to be authenticated to make sure they are legitimate and authorized. ML will enhance the authentication process, including password management, phishing prevention, and malware detection.

Areas that bad actors look to exploit are software design vulnerabilities and weak points in systems and networks. Once hackers uncover these vulnerabilities, they can be used as a point of entrance to the network or systems. ML can detect these vulnerabilities and alert administrators.

Taking a proactive approach by doing threat detection is essential in cyber defense. ML pattern and behavioral analysis strengths support this strategy. When ML detects unusual behavior in data traffic flow or patterns, it sends an alert about abnormal behavior to the administrator. This is similar to the banking industry’s practice of watching for credit card use that does not follow an established pattern. A large purchase overseas on a credit card with a pattern of U.S. use only for moderate amounts would trigger an alert, for example.

As hackers become more sophisticated with new attack vectors, whether it is new ransomware or distributed denial of service (DDoS) attacks, ML will do a much better job than humans in detecting these unknown threats.

Limitations of ML in cybersecurity
While ML provides many benefits, its value depends on the data used to train it. The more that can be used to train the ML model, the better it is at detecting fraud and cyber threats. But acquiring this data raises overall cybersecurity system design expenses. The model also needs constant maintenance and tuning to sustain peak performance and meet the specific needs of users. And while ML can do many of the tasks, it still requires some human involvement, so it’s essential to understand both cybersecurity and how well ML functions.

While ML is effective in fending off many of the cyberattacks, it is not a panacea. “The specific type of artificial intelligence typically referenced in this context is machine learning (ML), which is the development of algorithms that can ingest large volumes of training data, then generalize and make meaningful observations and decisions based on novel data,” said Scott Register, vice president of security solutions at Keysight Technologies. “With the right algorithms and training, AI/ML can be used to pinpoint cyberattacks which might otherwise be difficult to detect.”

However, no one — at least in the commercial space — has delivered a product that can detect very subtle cyberattacks with complete accuracy. “The algorithms are getting better all the time, so it’s highly probable that we’ll soon have commercial products that can detect and respond to attacks,” Register said. “We must keep in mind, however, that attackers don’t sit still, and they’re well-funded and patient. They employ ‘offensive AI,’ which means they use the same types of techniques and algorithms to generate attacks which are unlikely to be detected.”

ML implementation considerations
For any ML implementation, a strong cyber defense system is essential, but there’s no such thing as a completely secure design. Instead, security is a dynamic and ongoing process that requires constant fine-tuning and improvement against ever-changing cyberattacks. Implementing ML requires a clear security roadmap, which should define requirements. It also requires implementing a good cybersecurity process, which secures individual hardware and software components, as well as some type of system testing.

“One of the things we advise is to start with threat modeling to identify a set of critical design assets to protect from an adversary under confidentiality or integrity,” said Jason Oberg, CTO at Cycuity. “From there, you can define a set of very succinct, secure requirements for the assets. All of this work is typically done at the architecture level. We do provide education, training and guidance to our customers, because at that level, if you don’t have succinct security requirements defined, then it’s really hard to verify or check something in the design. What often happens is customers will say, ‘I want to have a secure chip.’ But it’s not as easy as just pressing a button and getting a green check mark that confirms the chip is now secure.”

To be successful, engineering teams must start at the architectural stages and define the security requirements. “Once that is done, they can start actually writing the RTL,” Oberg said. “There are tools available to provide assurances these security requirements are being met, and run within the existing simulation and emulation environments to help validate the security requirements, and help identify any unknown design weaknesses. Generally, this helps hardware and verification engineers increase their productivity and build confidence that the system is indeed meeting the security requirements.”

Fig. 1: A cybersecurity model includes multiple stages, progressing from the very basic to in-depth. It is important for organizations to know what stages their cyber defense system are. Source: Cycuity

Steve Garrison, senior vice president, marketing of Stellar Cyber, noted that if cyber threats were uncovered during the detection process, so many data files may be generated that they will be difficult for humans to sort through. Graphical displays can speed up the process and reduce the overall mean time to detection (MTTD) and mean time to response (MTTR).

Fig. 2: Using graphical displays  would reduce the overall meantime to detection (MTTD) and meantime to response (MTTR). Source: Stellar Cyber

Testing is essential
Another important stage in the design process is testing, whereby each system design requires a vigorous attack simulation tool to weed out the basic oversights to ensure it meets the predefined standard.

“First, if you want to understand how defensive systems will function in the real world, it’s important to test them under conditions, which are as realistic as possible,” Keysight’s Register said. “The network environment should have the same amount of traffic, mix of applications, speeds, behavioral characteristics, and timing as the real world. For example, the timing of a sudden uptick in email and social media traffic corresponds to the time when people open up their laptops at work. The attack traffic needs to be as realistic as possible as well – hackers try hard not to be noticed, often preferring ‘low and slow’ attacks, which may take hours or days to complete, making detection much more difficult. The same obfuscation techniques, encryption, and decoy traffic employed by threat actors needs to be simulated as accurately as possible.”

Further, due to mistaken assumptions during testing, defensive systems often perform great in the lab, yet fail spectacularly in production networks.  “Afterwards we hear, for example, ‘I didn’t think hackers would encrypt their malware,’ or ‘Internal e-mails weren’t checked for malicious attachments, only those from external senders,’” Register explained. “Also, in security testing, currency is key. Attacks and obfuscation techniques are constantly evolving. If a security system is tested against stale attacks, then the value of that testing is limited. The offensive tools should be kept as up to date as possible to ensure the most effective performance against the tools a system is likely to encounter in the wild.”

Semiconductor security
Almost all system designs depend on semiconductors, so it is important to ensure that any and all chips, firmware, FPGAs, and SoCs are secure – including those that perform ML functionality.

“Semiconductor security is a constantly evolving problem and requires an adaptable solution, said Jayson Bethurem, vice president marketing and business development at Flex Logix. “Fixed solutions with current cryptography that are implemented today will inevitably be challenged in the future. Hackers today have more time, resources, training, and motivation to disrupt technology. With technology increasing in every facet of our lives, defending against this presents a real challenge. We also have to consider upcoming threats, namely quantum computing.”

Many predict that quantum computing will be able to crack current cryptography solutions in the next few years. “Fortunately, semiconductor manufacturers have solutions that can enable cryptography agility, which can dynamically adapt to evolving threats,” Bethurem said. “This includes both updating hardware accelerated cryptography algorithms and obfuscating them, an approach that increases root of trust and protects valuable IP secrets. Advanced solutions like these also involve devices randomly creating their own encryption keys, making it harder for algorithms to crack encryption codes.”

Advances in AI/ML algorithms can adapt to new threats and reduce latency of algorithm updates from manufacturers. This is particularly useful with reconfigurable eFPGA IP, which can be implemented into any semiconductor device to thwart all current and future threats and optimized to run AI/ML-based cryptography solutions. The result is a combination of high-performance processing, scalability, and low-latency attack response.

Chips that support AI/ML algorithms need not only computing power, but also accelerators for those algorithms. In addition, all of this needs to happen without exceeding a tight power budget.

“More AI/ML systems run at tiny edges rather than at the core,” said Detlef Houdeau, senior director of design system architecture at Infineon Technologies. “AI/ML systems don’t need any bigger computer and/or cloud. For instance, a Raspberry Pi for a robot in production can have more than 3 AI/ML algorithms working in parallel. A smartphone has more than 10 AI/ML functions in the phone, and downloading new apps brings new AI/ML algorithms into the device. A pacemaker can have 2 AI/ML algorithms. Security chips, meanwhile, need a security architecture as well as accelerators for encryption. Combining an AI/ML accelerator with an encryption accelerator in the same chip could increase the performance in microcontroller units, and at the same time foster more security at the edge. The next generation of microelectronics could show this combination.”

After developers have gone through design reviews and the systems have run vigorous tests, it helps to have third-party certification and/or credentials to ensure the systems are indeed secure from a third-party independent viewpoint.

“As AI, and recently generative AI, continue to transform all markets, there will be new attack vectors to mitigate against,” said Arm’s Maidment. “We expect to see networks become smarter in the way they monitor traffic and behaviors. The use of AI/ML allows network-based monitoring at scale to allow potential unexpected or rogue behavior to be identified and isolated. Automating network monitoring based on AI/ML will allow an extra layer of defense as networks scale out and establish effectively a ‘zero trust’ approach. With this approach, analysis at scale can be tuned to look at particular threat vectors depending on the use case.”

With an increase in AI/ML adoption at the edge, a lot of this is taking place on the CPU. “Whether it is handling workloads in their entirety, or in combination with a co-processor like a GPU or NPU, how applications are deployed across the compute resources needs to be secure and managed centrally within the edge AI/ML device,” Maidment said. “Building edge AI/ML devices based on a hardware root of trust is essential. It is critical to have privileged access control of what code is allowed to run where using a trusted memory management architecture. Arm continually invests in security, and the Armv9 architecture offers a number of new security features. Alongside architecture improvements, we continue to work in partnership with the industry on our ecosystem security framework and certification scheme, PSA Certified, which is based on a certified hardware RoT. This hardware base helps to improve the security of systems and fulfill the consumer expectation that as devices scale, they remain secure.”

Outlook
It is important to understand that threat actors will continue to evolve attacks using AI/ML. Experts suggest that to counter such attacks, organizations, institutions, and government agencies will have to continually improve defense strategies and capabilities, including AI/ML deployment.

AI/ML can be used as weapon from an attacker for industrial espionage and/or industrial sabotage, and stopping incursions will require a broad range of cyberattack prevention and detection tools, including AI/ML functionality for anomaly detection. But in general, hackers are almost always one step ahead.

According to Register, “the recurring cycle is: 1) hackers come out with a new tool or technology that lets them attack systems or evade detection more effectively; 2) those attacks cause enough economic damage that the industry responds and develops effective countermeasures; 3) the no-longer-new hacker tools are still employed effectively, but against targets that haven’t bothered to update their defenses; 4) hackers develop new offensive tools that are effective against the defensive techniques of high-value targets, and the cycle starts anew.”

Related Reading
Securing Chip Manufacturing Against Growing Cyber Threats
Suppliers are the number one risk, but reducing attacks requires industry-wide collaboration.
Data Center Security Issues Widen
The number and breadth of hardware targets is increasing, but older attack vectors are not going away. Hackers are becoming more sophisticated, and they have a big advantage.

The post Using AI/ML To Combat Cyberattacks appeared first on Semiconductor Engineering.

Advanced process nodes and higher silicon densities are heightening DRAM’s susceptibility to Rowhammer attacks, as reduced cell spacing significantly decreases the hammer count needed for bit flips.

Rowhammer exploits DRAM’s single-capacitor-per-bit design to trigger bit flips in adjacent cells through repeated memory row accesses. This vulnerability allows attackers to manipulate data, recover sensitive information, and crash processes or systems. First identified in 2014, evolving Rowhammer variants continue to target DRAM, successfully bypassing security techniques such as error correction code (ECC) and transactional row refresh (TRR).

Fig. 1: DRAMs on a DIMM, with corresponding mapping of row addresses and DRAM banks. A RowHammer attack can flip bits in the same victim row in multiple DRAMs, overwhelming ECC protection. Source: Rambus

Effectively protecting DRAM against Rowhammer requires a multi-layer, system-level implementation of robust security techniques, from encryption and obfuscation to enforced data isolation and advanced error correction schemes. This is easier said than done, however, as countermeasures can potentially impact power, performance, and area (PPA). Engineers should therefore evaluate PPA-security tradeoffs alongside key features and components at the start of the design process.

A top-down, system-level approach to securing DRAM
“Security is always a cat-and-mouse game, and the evolution of Rowhammer attacks and defenses is no different,” said Nicole Fern, senior security analyst at Riscure. “Researchers have demonstrated successful Rowhammer attacks on commercial DRAM modules employing both TRR and ECC, recovering TLS signing keys in several cryptographic libraries (Amazon-s2n (CVE-2022-42962), WolfSSL (CVE-2022-42961), and LibreSSL (CVE-2022-42963). Many speculate that real-world attacks are imminent. For countermeasures, the question should not be, ‘Will they ultimately be able to counter Rowhammer attacks in general?’ Rather, the question should be: ‘For a specific system and threat model, is the attack effort greater than the value of the assets being targeted and costs of a successful attack?’”

Traditionally, only PPA tradeoffs are considered during the silicon design process. However, recent hardware-based attacks, including Rowhammer, Meltdown, and Spectre, and those exploiting DVFS features to inject faults from software—such as clkscrew and Plundervolt—highlight the importance of prioritizing security during the design process. “Often, it is new features added for performance that create a foothold for attacks,” explained Fern. “As DRAM technology [nodes] shrink over time, with density and performance improving, susceptibility to Rowhammer increases. [Engineers] need to be aware of this effect and proactively design in appropriate countermeasures — with thorough testing ensuring these perform as expected as DRAM technology evolves.”

Jason Oberg, co-founder and CTO at Cycuity, agrees. “Hardware susceptibility is a key component of a larger chain of weaknesses used to exploit vulnerabilities. Rowhammer, a physical attack that’s done remotely, is one of those easy-to-exploit vectors, because if you can flip or modify a bit, you can chain that together with other software-based exploits. In isolation, it may be less of an issue, but in the context of a bigger strain of weaknesses that someone is exploiting, it’s problematic. Many systems vulnerable to Meltdown and Spectre, for example, are also points of concern for exploits like Rowhamer. You wouldn’t worry about these attacks on your smart light bulb or robot vacuum, but I would be concerned about my phone or laptop.”

To address these concerns, various encryption and obfuscation techniques have been proposed to protect DRAM from Rowhammer attacks. “If you encrypt or obfuscate your data, and then someone hammers a row and causes bits to flip, they won’t be able to target a specific bit,” Oberg explained. “They won’t know what the specific bit is. Whereas if it’s just plain text and it’s like a supervisor bit and they know where that supervisor bit is, then they can be very direct with what they’re doing.”

Although these techniques are crucial, Oberg emphasized that security considerations must be part of the design process, starting at the architectural level. “If I’m building a chip using licensed IP, I need to take a step back, analyze its function, and determine the assets that need to be protected,” Oberg noted. “From there, you can license a hardware-based root of trust. Maybe you trust one and not the other, even though it’s cheaper. These are the kind of decisions you should drive at the top level, and then try to manage as best you can without having full control of everything in your supply chain.”

Analyzing a system holistically also allows the design team to reduce the impact of security mitigation on PPA. “If you jump straight into saying, ‘I am concerned about memory,’ then you’re already very isolated,” he said. “If you start picking at each of the weaknesses independently, then the overhead goes up a lot higher because there may be an overlap between [mitigation techniques]. So you should take a higher-level view. It’s important to look at that top level and then drive your security program from that level. If you drive it from the bottom up, you’re going to have huge overheads, a lot of complexity, and you’re going to have problems.”

Ultimately, Oberg sees a combination of system-wide hardware and software solutions, paired with strict access controls and enforced data isolation, as a more effective method of countering exploits like Rowhammer. “In any multi-tenant or shared environment, containers are needed to isolate data. Data should also be assigned, for example, to processor thread A where it can’t be read by another thread. Of course, it can’t just be software. Foundation-level hardware protections are required. Otherwise, software protection will be subverted.”

Siloing processes and tagging memory
Kos Gitchev, senior technical market manager at Cadence, pointed to Arm’s confidential compute architecture (CCA) and memory tagging extension (MTE) as examples of a multi-layered, system-centric defense strategy against various attacks and exploits, including Rowhammer and RAMBleed. CCA ensures data protection during processing by isolating or siloing computation in a secure, hardware-backed environment, while MTE tags memory allocations with metadata that is verified during runtime operations. Although not specifically designed to counter Rowhammer or RAMBleed, both mechanisms help protect against such exploits.

“A Rowhammer attacker can’t say: ‘Well, I’ve taken over the machine and I want to go read this memory,’” Gitchev explained. “If you don’t have the appropriate MTE tags for your process, then you won’t be able to read it. The system will basically block it.”

To protect data held in DRAM, 128-bit or 256-bit AES encryption is also essential. “This is generally done by the memory subsystem, not the DRAM itself,” Gitchev noted. “Blocks of data will come in, they’ll get encrypted, and then pass to the memory. If anything happens to the encrypted data, it won’t properly decrypt. Encryption is almost always done in conjunction with ECC, so there are almost two layers of protection when you implement this scheme.”

Gitchev emphasized that encryption is only effective if keys are properly managed and secured. “A memory subsystem does the encryption. It has the algorithm and adds the XTS extension. Even when you write two blocks of the same data, they’ll look different on the bus to the memory. Of course, all of this can be overcome if someone compromises the encryption key.”

AES encryption can be added without major PPA penalties, making it an optimal choice for memory subsystems. “There are many different encryption schemes out there, but AES is easiest to implement,” said Gitchev. “Adding encryption, however, does increase the number of gates and power. To be fair, most of the memory subsystem power goes into driving the interface [for transferring data off-chip to the memory and back]. There is also a little bit of performance and area cost. The memory subsystem is now bigger because it needs to execute complex mathematical calculations for encryption and decryption in real time without significant latency.”

Tightly coupling encryption and decryption ciphering functions inside the DDR or LPDDR controllers facilitates maximum memory efficiency and lowest overall latency. “When doing both functions separately, certain functionality may have to be repeated, such as bus interface logic or support for read-modify-write operations,” said Ruud Derwig, system architect, solutions group at Synopsys. “When tightly integrated, the scheduler inside the controller can request encryption and decryption at the most optimal times, for example, when overlapping other controller operations or while waiting for data.”

Rowhammer and its variants aren’t necessarily the primary drivers for memory encryption solutions that require secure key management. “Inline memory encryption (IME) is mainly intended to defend against cold-boot attacks and provide confidential compute features,” Derwig said. “For example, a newly created virtual machine (VM) or process may get access to physical memory pages used previously by another VM or process when memory is not erased first, compromising the confidentiality of that previous computing context. With proper key management, IME mitigates these compromises. Or, when the hypervisor itself cannot be trusted, confidentiality of user data is still guaranteed by using different IME keys for different privilege levels and VMs.”

Nevertheless, IME contributes to Rowhammer attack countermeasures, as post-encryption data in the memory appears random to attackers. “Certain data patterns — rowstriped or checker patterns, for example — give the highest success rate for row hammering,” Derwig elaborated. “Moreover, when a single or a few bits are flipped, this is amplified to a full 128-bit decrypted block getting random data, so exploiting bit flips becomes much harder. When there is no attacker control over the changes, it is more likely to get detected by causing malfunctioning. IME [also offers] cryptographically strong integrity protection that mitigates bypassing less strong ECC protection.”

The cycle of Rowhammer attacks and countermeasures will continue as new vulnerabilities are identified and addressed. “Multi-level defenses and mitigations, such as hardware design of memory chips and memory controllers, as well as system software mitigations in hypervisors and operating systems, are needed to [counter] evolving threats,” Derwig added.

Bolstering DRAM reliability in data centers
Although Rowhammer can target any device equipped with DRAM, protecting the data center remains a priority for the semiconductor industry and many security researchers. “New memory used to debut in high-performance PCs and then move into servers,” said Steven Woo, fellow and distinguished inventor at Rambus Labs. “These days, new memory technologies debut for AI [applications] in data centers. The concern is, ‘What if somebody gains access to many servers in the data center and launches programs that intentionally try to repeatedly activate addresses?’ If enough bits flip and can’t be corrected, it could cause what looks like a large hardware fault. You might have to take down memory channels or a machine.”

While the risks of Rowhammer and other exploits in the data center are well known, the semiconductor industry may need more time to comprehensively bolster DRAM security and reliability at the design and system levels. “If you go back 25 or 30 years, nobody was really that concerned about power,” Woo stated. “You can dissipate the heat. You just burn a little more power to get more performance. But today, power is a first-class design parameter that everybody thinks about. Reliability is in that same place that power was in the 2000 to 2005 timeframe, where people are starting to realize, ‘Well, wait a minute, things aren’t infinitely reliable. We’re now going to have to consider DRAM reliability as a first-class design parameter.'”

As DRAM process geometries continue to shrink, electronic engineers will need to develop new or improved architectures and techniques that resist deliberate and repeated errors caused by attackers. “And the tradeoff is, ‘What are you willing to pay to do that? Is there a performance hit? Is there an area hit? Are we storing lots of extra bits?’ In 10 years, we’ll look back and we’ll be talking about reliability in the same way that we talk about power today,” he said.

Bolstering DRAM security and reliability without significantly impacting PPA was the primary driver behind the development of Rambus Labs’ RAMPART: Rowhammer mitigation and repair for server memory systems. Essentially, RAMPART mitigates Rowhammer attacks and improves server memory system reliability by remapping addresses in each DRAM, confining bit flips to a single device for any victim row address. When paired with existing error detection and correction methods, such as single-device data correction (SDDC) and patrol scrub, the system successfully detects and corrects bit flips. To effectively minimize mitigation overhead, RAMPART employs BRC-VL, a variation of DDR5’s bounded refresh configuration (BRC).

Fig. 2: RAMPART row address mappings produce unique neighbors, so Rowhammer attacks have different victim addresses in each DRAM. (a) Circular left shifts of controller row addresses based on unique DRAM IDs are shown. The tables at the bottom illustrate how controller row addresses map to internal bank rows in each DRAM. Row addresses 0x0000 and 0x0001 are bolded to highlight increasing separation with larger shifts. (b) Hammering controller row address 0x0001 flips bits in controller row addresses 0x0000 and 0x0002 in DRAM 0, but controller row addresses 0x8000 and 0x8001 in DRAM 1. A subsequent read to controller row address 0x0000 sees errors only from DRAM 0 that can be corrected with SDDC ECC. Source: Rambus

Assuming 70% area utilization and conservative routing, RAMPART reaches a speed of 2.85GHz in an area of 3910µm², or roughly 51K NAND2 gates. For a server with 1,024 banks, the total area required is only 0.1251mm². “We did a sample implementation at TSMC’s 7nm process, showing RAMPART’s small [footprint],” Woo said. “The controller side of it that does the tracking and figures out how often to issue a mitigation operation is very small, just a few gates. It’s very reasonable to implement something like this in a memory controller, and it has no die size impact as far as we can tell. There’s no latency impact on the accesses. It’s a very simple remapping change. And the DRAM is already doing remapping, so it’s not like asking for a new function. It’s simply modifying an existing function.

Conclusion
The continued proliferation of new and improved Rowhammer variants highlights the critical importance of implementing multi-layered, system-level countermeasures to protect DRAM, alongside of other key components and features. These should encompass a wide range of security techniques, from encryption and obfuscation to advanced error correction, address remapping, and data isolation. Still, to fully optimize performance and minimize latency, PPA security tradeoffs must be assessed from the top down at the start of the design process.

Related Reading
Power/Performance Costs Of Securing Systems
Security requires significant overhead, but it is no longer an option to ignore it. Cybercriminals will continue to exploit weak components.
Developing An Unbreakable Cybersecurity System
New approaches are in research, but threats continue to grow.
DRAM Choices Are Suddenly Much More Complicated
The number of options and tradeoffs is exploding as multiple flavors of DRAM are combined in a single design.

The post Securing DRAM Against Evolving Rowhammer Threats appeared first on Semiconductor Engineering.

In early 2018, the tech industry was shocked by the discovery of hardware microarchitecture vulnerabilities that bypassed decades of work put into software and application security. Meltdown and Spectre exploited performance features in modern application processors to leak sensitive information about victim programs to an adversary. This leakage occurs through the hardware itself, meaning that malicious software can extract secret information from users even if software protections are in place because the leakages happen below the view of software in hardware. Since these so-called transient execution vulnerabilities were first publicly disclosed, dozens of variants have been identified that all share a set of common root cause weaknesses, but the specifics of that commonality were not well understood broadly by the security community.

In early 2020, Intel Corporation, MITRE, Cycuity, and others set off to establish a set of common weaknesses for hardware to enable a more proactive approach to hardware security to reduce the risk of a hardware vulnerability in the future. The initial set of weaknesses, in the form of Common Weakness Enumerations (CWE), were broad and covered weaknesses beyond just transient execution vulnerabilities like Meltdown and Spectre. While this initial set of CWEs was extremely effective at covering the root causes across the entire hardware vulnerability landscape, the precise and specific coverage of transient execution vulnerabilities was still lacking. This was primarily because of the sheer complexity, volume, and cleverness of each of these vulnerabilities.

In the fall of 2022, technical leads from AMD, Arm, Intel (special kudos to Intel for initiating and leading the effort), Cycuity, and Riscure came together to dig into the details of publicly disclosed transient execution vulnerabilities to really understand their root cause and come up with a set of precise, yet comprehensive, root cause weaknesses expressed as CWEs to help the industry not only understand the root cause for these microarchitecture vulnerabilities but to help prevent future, unknown vulnerabilities from being discovered. The recent announcement of the four transient execution weaknesses was a result of this collaborative effort over the last year.

CWEs for microarchitecture vulnerabilities

To come up with these root cause weaknesses, we researched every known publicly disclosed microarchitecture vulnerability (Common Vulnerabilities and Exposures [CVEs]) to understand the exact characteristics of the vulnerabilities and what the root causes were. As a result of this, the following common weaknesses were discovered, with a brief summary provided in layman terms from my perspective:

CWE-1421: Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution

• Potentially leaky microarchitectural resources are shared with an adversary. For example, sharing a CPU cache between victim and attacker programs has shown to result in timing side channels that can leak secrets about the victim.

CWE-1422: Exposure of Sensitive Information caused by Incorrect Data Forwarding during Transient Execution

• The forwarding or “flow” of information within the microarchitecture can result in security violations. Often various events (speculation, page faults, etc.) will cause data to be incorrectly forwarded from one location of the processor to another (often to a leaky microarchitecture resource like the one listed in CWE-1421)

CWE-1423: Exposure of Sensitive Information caused by Shared Microarchitectural Predictor State that Influences Transient Execution

• An attacker being able to affect or “poison” a microarchitecture predictor used within the processor. For example, branch prediction is commonly used to increase performance to speculatively fetch instructions based on the expected outcome of a branch in a program. If an adversary is able to affect the branch prediction itself, they can cause the victim to execute code in branches of their choosing.

CWE-1420: Exposure of Sensitive Information during Transient Execution

• A general transient execution weakness if one of the other weaknesses above do not quite fit the need.

Within each of the CWEs listed above, you can find details about observed examples, or vulnerabilities, which are a result of these weaknesses. Some vulnerabilities, Spectre-V1, for example, requires the presence of CWE-1421, CWE-1422, and CWE-1423. While others, like Meltdown, only require CWE-1422 and CWE-1423.

Since detecting these weaknesses can be a daunting task, each of the CWEs outline a set of detection methods. One detection method that is highlighted in each CWE entry is the use of information flow to track the flow of information in the microarchitecture to ensure data is being handled securely. Information flow can be used for each of the CWEs as follows:

• CWE-1421: information flow analysis can be used to ensure that secrets never end up in a shared microarchitectural resource.
• CWE-1422: ensure that secret information is never improperly forwarded within the microarchitecture.
• CWE-1423: ensure that an attacker can never affect or modify the predictor state in a way that is observable by the victim. In other words, information from the attacker should not flow to the predictor if that information can affect the integrity of the predictor for the victim.

Our Radix products use information flow at their core and we have already shown success in demonstrating Radix’s ability to detect Meltdown and Spectre. We look forward to continuing to work with the industry and our customers and partners to further advance the state of hardware security and reduce the risk of vulnerabilities being discovered in the future.

The post Microarchitecture Vulnerabilities: Uncovering The Root Cause Weaknesses appeared first on Semiconductor Engineering.