Convenient remote management tools save system administrators a lot of energy - and at the same time pose a huge security risk when they cannot be disabled by hardware using a jumper or switch on the system board. The Intel Management Engine 11 block in modern Intel platforms is just such a danger - it is initially non-disconnectable and, moreover, some mechanisms of initialization and processor operation are tied to it, so a rough deactivation can simply lead to a complete inoperability of the system. The vulnerability lies in Intel Active Management Technology (AMT) and, with a successful attack, allows you to get full control over the system, as was reported back in May this year. But researchers from Positive Technologies.
The IME processor itself is part of the System Hub Chip (PCH). With the exception of PCI Express processor slots, all communication between the system and the outside world passes through the PCH, which means that the IME has access to almost all data. Prior to version 11, an attack against this vector was unlikely: the IME processor used its own architecture with the ARC instruction set, which was little known to third-party developers. But in version 11, they played a bad joke with the technology: it was transferred to the x86 architecture, and a modified MINIX was used as the OS, which means that third-party studies of the binary code have become much easier: both the architecture and the OS are well documented. Russian researchers Dmitry Sklyarov, Mark Ermolov and Maxim Goryachy managed to decipher the executable modules of IME version 11 and begin their thorough study.
Intel AMT is rated 9.8 out of 10 for vulnerability. Unfortunately, completely disabling the IME on modern platforms is impossible for the above reason - the subsystem is closely related to the initialization and startup of the CPU, as well as power management. But you can remove all unnecessary elements from the flash memory image containing IME modules, although it is very difficult to do this, especially in version 11. The me_cleaner project, a utility that allows you to remove the common part of the image and leave only vital components, is actively developing. But let's give a small comparison: if in IME versions up to 11 (before Skylake) the utility deleted almost everything, leaving about 90 KB of code, then at present it is necessary to save about 650 KB of code - and then in some cases the system may shutdown after half an hour, since the block IME enters recovery mode.
However, there are some progress. The aforementioned group of researchers managed to use a development kit, which is provided by Intel itself, and includes Flash Image Tool utilities for configuring IME parameters and a Flash Programming Tool flasher that works through an integrated SPI controller. Intel does not make these programs publicly available, but it is not difficult to find them on the Internet.
The XML files obtained with this kit were analyzed (they contain the IME firmware structure and a description of the PCH strap mechanism). One bit called "reserve_hap" (HAP) seemed suspicious due to the description of "High Assurance Platform (HAP) enable". A web search revealed that this is the name of a high-power platform program associated with the US NSA. Enabling this bit indicated that the system entered Alt Disable Mode. The IME block did not respond to commands and did not respond to influences from the operating system. There are also a number of more subtle nuances that can be found in the article on Habrahabr.ru, but the new version of me_cleaner has already implemented support for most of the dangerous modules without setting the HAP bit, which puts the IME engine into the "TemporaryDisable" state.
The last modification of me_cleaner leaves only the RBE, KERNEL, SYSLIB and BUP modules even in the 11th version of the IME, they did not find a code that allows you to enable the IME system itself. In addition to these, you can use the HAP bit to make sure that the utility can do it too. Intel has reviewed the research and has confirmed that a number of IME settings are indeed related to government needs for enhanced security. These settings were introduced at the request of US government customers and have undergone limited validation and are not officially supported by Intel. The company also denies the introduction of so-called backdoors into its products.
In short, it states the following (hereinafter, in the text, my subjective free retelling).
Allegedly, large corporations around the world, including Apple, Amazon and others like them, have ordered expensive top-end servers from SuperMicro for many years. The latter was a ** eating from such volumes of orders, her own factories were no longer able to cope. Then she gave the production of a certain amount of motherboards to her Chinese subcontractors.
Chinese polite people came to these same subcontractors and made them an offer that cannot be refused. Like, come on, guys, at our request, at our request, you will additionally install one more ma-a-a-a-scarlet such undocumented chip on your motherboards. If you do - we will bring you additional money, but if you don’t do it, we will put down your business with various checks. As a result, motherboards "modified" in this way were sold all over the world, and some of them also ended up in large American companies of the first echelon, banks, and government agencies.
Some time passed. One of the divisions of Amazon, a certain company called "Elements", took care of the security of its solutions in the field of mass processing of video streams. Among other things, they ordered a hardware security audit of a certain Canadian firm. And it was here that undocumented chips skillfully hidden implanted into motherboards were discovered. Which are, like, not so easy to find. Because, firstly, they are very small and gray. Secondly, they disguise themselves as ordinary soldering couplings or chip capacitors. Thirdly, in the last revisions they began to be hidden right in the thickness of the textolite, so that they are visible only on X-rays.
If you believe the text, then by means of the embedded microcode, the spy chip through the BMC module periodically "pings" one of its anonymous "puppeteers", from whom it receives further instructions for action. And supposedly even the aforementioned adversary is able to download "from where" some code, which is then injected directly into the running operating system kernel or into the application code.
Well, further rantings follow about how big a hole in security is, what kind of goats these Chinese are, what their audacity and impudence are, all the goats cannot be trusted, "now we are all going to die" and that's all. Technically interesting reasoning ends there.
In general, I am a big skeptic in life. Without denying the genius of the Chinese, some moments personally seem to me rather unrealistic. To take it just like that, on the sly from engineers and management, and make changes to the design of the motherboard at the manufacturer's level, without disrupting its performance? And if with the knowledge of the management, then how was he motivated to expose all such large business to such a serious reputational risk? Inject your code into the operating system and applications? Well, with Windows, it's okay, I'm ready to believe with a creak. But in Linux, where you do not know in advance who and how it collected? Exercise fingerless network activity? Which, if desired, can be detected and filtered. Not to mention the fact that normal admins never expose BMCs "to show their bare ass on the Internet", and good admins generally throw them into a separate VLAN without the ability to access anywhere.
Well, again, recently some fierce spy mania and paranoia have progressed among the Americans. And they also decided to quarrel with China. So the objectivity and impartiality of the original article is a big question. On the other hand, I don't understand very well where they get such beautiful subjects from. Back in 2011, the tabloid magazine "Ksakep" wrote about the same Chinese bookmarks at the microcode level in the BMC flash drive. That article also smacks of paranoid delirium, but there is no smoke without fire. Or does it happen?
In general, share your opinion in the comments. It is especially interesting to hear Comrade kvazimoda24 on the possibility of integrating some kind of spy microcircuits into the thickness of the PCB.
I am not a professional in the field of information security, my area of \u200b\u200binterest is high-performance computing systems. I came to the topic of information security quite by accident, and this is what will be discussed further. I think this fictional story will better illuminate the problems associated with virtualization hardware than a dry statement of facts. Even before the official announcement of new Intel processors with support for hardware virtualization (in early 2007), I conceived of using these chips to create a single computing system based on several servers, which would become a single computing unit with an SMP architecture for the OS and applications. To do this, it was required to write a compact hypervisor with non-standard functionality, the main feature of which would not be the division of the resources of a single computing unit between different operating systems, but, on the contrary, the unification of the resources of several computers into a single complex, which would be controlled by one OS. At the same time, the OS did not even have to guess that it was dealing not with a single system, but with several servers. Virtualization hardware provided such an opportunity, although it was not originally intended to solve such problems. Actually, a system in which virtualization hardware would be used for high-performance computing has not yet been created, and even at that time I was generally a pioneer in this area. The hypervisor for this task, of course, was written from scratch. It was fundamentally important to run the OS already on a virtualized platform so that from the first commands of the OS loader everything would work in a virtual environment. To do this, we had to virtualize the real model and all modes of processor operation and start virtualization immediately after initializing the platform before loading the OS. Since the virtualization system for this purpose turned out to be non-standard and looked like a completely autonomous compact software module (code size no more than 40-60 Kb), the language somehow did not dare to call it a hypervisor, and I began to use the term "hyperdriver", since it is more accurate conveyed the essence of the functional purpose of the system. Serial equipment with virtualization hardware was not yet available at that time, however, thanks to cooperation with Craftway, I had access to pre-production samples of processors and motherboards with virtualization support, which were not yet officially released (so-called samples, which Intel kindly provides to its business partners). Therefore, the work began to boil on this "sample" equipment. The mockup was assembled, the hyperdriver was written, everything worked as intended. I must say that at that time the virtualization hardware was very "raw", which is why it repeatedly refused to work as written in the documentation. I had to deal with literally every assembler command, and the commands for the virtualization hardware had to be written in machine codes, since then there were no compilers with support for virtualization commands. I was proud of the results obtained, I felt almost the lord of virtual worlds ... but my euphoria did not last long, only a month. By that time, I had already assembled a layout based on servers with virtualization equipment, the first serial samples of which had just appeared, but the layout did not work. I started to figure it out and realized that my system hangs when executing hardware virtualization commands. The impression was that they either did not work at all, or worked somehow outside the box. Hanging occurred only when the virtualization hardware was running in real mode, but if my system was started from protected mode after the OS was loaded, then everything was fine. Pros know that in the early revisions, Intel's virtualization hardware did not support real-time processor operation. This required an additional layer large enough to emulate virtual x86. Since the hyperdriver was started before the operating system was loaded, so that it could fully believe in the new virtual configuration, a small chunk of the OS boot code was executed in real mode of the processor. The system died just on the real mode emulation handlers in the hyperdriver. At first I thought that I was mistaken somewhere, did not understand something, forgot about something. I checked everything to the last bit in my code, did not find any errors and began to sin not on myself, but on my colleagues from behind the hill. The first thing I did was to replace the processors, but that didn't help. On motherboards at that time, the virtualization hardware was only in the BIOS, where it was initialized when the server was turned on, so I started comparing the bios on motherboards (motherboards of the same type with samples) - everything matched up to the byte and the number of the BIOS itself. I fell into a stupor and, no longer knowing what to do, applied the last resort - the "poke method". What did I not do, no longer thinking, but simply combining, and in the end I stupidly downloaded bios from the official Intel website and rewrote them into motherboards, after which everything worked ... There was no limit to my surprise: the BIOS number was the same , the BIOS images matched byte by byte, but for some reason the serial motherboards only started working when I uploaded the same BIOS taken from the Intel website into them. So, the reason is still in the motherboards? But their only difference was in the marking: Assembled Canada was written on the samples, and Assembled China on the serial boards. It became clear that the boards from China contain additional software modules embedded in the BIOS, but these modules were not seen by the standard analysis programs. They, apparently, also worked with virtualization hardware and, accordingly, were able to hide the true contents of the BIOS. The reason for the freezes of my hyperdriver on these Chinese boards also became clear: two software systems were simultaneously working with the same virtualization hardware, which did not allow sharing their resources. I wanted to deal with this malicious bios, and without any second thought about "bookmarks", "backdoors", "undocumented features", there was just academic interest, and nothing more. I must say that in parallel with the introduction of virtualization hardware, Intel radically updated the chipset. This chipset, numbered 5000x, is still being produced in several modifications. The south bridge of this chipset, 631xESB / 632xESB I / O Controller Hub, to which flash microcircuits with bios are connected, has been practically unchanged since 2007 and is used as a base chip for almost all servers in a two-socket version. I downloaded the datasheet for the south bridge, read the description and was stunned. It turns out that three flash memory chips are connected to this new south bridge: the first is a standard BIOS, the second is dedicated to the network controller processor programs, and the third is intended for the BMC unit integrated into the south bridge. The system management unit (BMC) is a means of remote control and monitoring of the computing facility. It is indispensable for large server rooms, where it is simply impossible to stay for a long time due to noise, temperature and drafts. The fact that the BMC units have their own processor and, accordingly, flash memory for its programs, of course, is not news, but until now such a processor and memory were taken out on a separate board that was connected to the motherboard: if you want - put it, you don't want to - do not put it. Now Intel has implemented these components in the south bridge, moreover, it connected this unit to the system bus and did not use a dedicated network channel (as provided by the IPMI standard describing the functions of the BMC unit) for the operation of the service network, but tunneled all service network traffic into the main network adapters. Then I learned from the documentation that the programs on the flash microcircuit of the BMC unit are encrypted, and a special hardware cryptographic module, also integrated into the south bridge, is used to unpack them. Such units of the Navy have never come across to me before. Not to be unfounded, here is an excerpt from the documentation for this south bridge:
- ARC4 processor working at 62.5 MHz speed.
- Interface to both LAN ports of Intel® 631xESB / 632xESB I / O Controller Hub allowing direct connection to the net and access to all LAN registers.
- Cryptographic module, supporting AES and RC4 encryption algorithms and SHA1 and MD5 authentication algorithms.
- Secured mechanism for loadable Regulated FW.
- Intel's new 5000 series server boards contain programs that are embedded in the flash memory of the BMC unit and run on the central processor, and these programs run using the virtualization hardware of the central processor.
- The flash memory images from the Intel official website do not contain such software modules, therefore, the software modules that interfere with me were illegally flashed into motherboards during the production stage.
- The flash memory of the BMC unit contains encrypted software modules that cannot be assembled and poured into flash memory without knowing the encryption keys, therefore, the one who inserted these illegal software modules knew the encryption keys, that is, had access to actually secret information.
The execution time shown in the photo is a certain conditional value, approximately corresponding to the processor cycle. Then I ran the same test on a serial motherboard and made sure of my paranoid assumptions - the command cycles were significantly lengthened. 
That is, in the flash memory of the BMC unit of server boards from China, manufactured under the Intel label, there was an undeclared software module installed at the production stage, which operates as a hypervisor host. It remains to convince others of this. The first thing I did was contact the Russian Intel representative. It was not difficult at all, since the employees of the Russian office often showed up at the Craftway. I told and showed everything, but I was not sure if the technician understood everything. These so-called technical specialists differ little from managers in terms of their competence. However, he promised to report everything to the management. I don't know if he did it, but there was no response from Intel, everything went like sand. By that time, my work at Craftway was over, and I started a new project in a company related to information security systems. The head of this firm, with whom I shared my "discoveries", took my words seriously. In this regard, it was decided to contact the leadership of the Center for Information Security and Special Communications of the FSB. This structure within the FSB is involved in ensuring information security in the country and regulates the activities of state and commercial organizations that are related to the protection of information. It also regulates information protection measures for government agencies and commercial firms that process classified and confidential information. The company in which I worked at that time maintained official contacts with the Center in order to certify and license their commercial projects, so it was quite easy to organize a meeting at the level of specialists. It was assumed that the experts of the Center would communicate their opinion to the management, and if after that the management deems it necessary to listen to us, the next stage will be a meeting at a higher level. The meeting took place, I told and showed everything that I could find out, then demonstrated the presence of an illegal software module on the examples of boards from Canada and China. By the way, that was the first time I heard the professional term "bookmark", which means such a module. When the conversation turned to the Navy, a misunderstanding appeared in the eyes of colleagues from the Center. I had to conduct an educational program. In the process, it turned out that they did not even suspect the existence of a special microprocessor in the south bridge with access to a network adapter and the presence of a cryptographic module in the naval unit that violates Russian law. In conclusion, we quite unexpectedly heard that this model of threats has already been investigated, a set of countermeasures is being applied in relation to them, and in general, we are not afraid of bookmarks, since our systems do not have an Internet connection. Further inquiries did not lead to anything, everything rested on secrecy, like, we are smart and super literate, and you are not supposed to know about anything. However, I strongly doubted their technical literacy, since they simply did not understand most of what I told and showed. We parted on what they would report to their superiors, and only they would decide on further actions. Later I found out what this "secret method" of detecting host programs was. And I found out quite by accident, during negotiations at the company - the licensee of the Center, authorized to check the BIOS for bookmarks. The technical specialists of this company, conducting research on the BIOS, said that its software modules using virtualization hardware should be searched for by the signatures of the virtualization commands. Indeed, processor instructions for virtualization hardware contain three or four bytes in the program code, but who said that they would find this program code in unencrypted form on a flash microcircuit? How do they scan this code into RAM if these areas of memory are protected from viewing by hardware? In general, the result of the first meeting left an unpleasant aftertaste, and in the gloomiest mood I expected the development of events. A month and a half later, we were invited to the Center for Information Protection and Special Communications itself so that we could demonstrate the bookmark we had discovered. This time, it was not ordinary employees who gathered to listen to us, but managers and leading specialists (at least that's how they introduced themselves). The meeting turned into a lecture, they listened to me attentively for almost three hours, it was clear that they were hearing for the first time what I was telling them about. I have listed new vulnerabilities in the x86 platform, showed the bookmark and told how to detect it, and answered many questions. At the end, they thanked us, said that the topic needed to be developed within the framework of special research projects, and on this we parted. The euphoria vanished when information reached us through unofficial channels that they simply did not want to believe us. However, this did not cool my desire to prove my case. As it seemed to me then, the solution lay on the surface: it was necessary to write such a program module for the bookmark myself. I would not have been able to put a bookmark in the flash memory of the Navy, but I could have shoved it into the main BIOS. I decided to equip the hypervisor with a module of its own security for masking in memory and on a flash microcircuit, as well as block writing to a flash microcircuit where the bookmark code will be placed, after which it will be possible to delete it only by desoldering the BIOS and reprogramming it on an external programmer. It only remained to decide on the "malicious" function that the hypervisor should perform. I remembered the statement of one of the FSB specialists that they are not afraid of bookmarks, since their systems are disconnected from the global network. But information from the outside world must somehow get into these secure local networks, at least through disposable optical disks. Thus, I came to the obvious conclusion and decided to analyze the incoming information flow in the tab by means of the hyperdriver in order to implement, so to speak, a doomsday weapon, that is, to use the tab to destroy the computing system on an external command, passing it through the input information stream, steganographically. To scan the information flow covertly, without losing performance, only virtualization hardware can handle it. At what point to scan, it is also clear: on the I / O buffers of disk systems and a network adapter. Scanning I / O buffers is a frustrating task for virtualization hardware. No sooner said than done! Such a hyperdriver, about 20 KB in size, was registered in the motherboard bios and is equipped with an anti-detection function. It blocked attempts to overwrite it when updating the BIOS and performed the only function: it reset the BIOS flash chip when a command for destruction was received. For ease of implementation, the command itself was sewn into a DOC-format text file in the settings tags. When everything was ready, the company's management again went to the FSB with a proposal to look at the work of our own bookmark and make sure that virtualization technologies pose a real threat. But no one wanted to look at our bookmark in the case, a command came from the very top (I never found out whose exact order it was) not to communicate with us anymore. The main fighters for information security did not want to listen to us. Then, already hoping for nothing, in fact, to clear our conscience, we tried to convey information about the problem to the users of information security systems. We contacted Gazprom to inform the company's specialists about the current threats to distributed process control systems. We managed to arrange a meeting with the management of the corporate security and management of complex security systems of this corporation. A more visual version of the bookmark with a simplified command interface was prepared especially for them. The bookmark was activated after downloading a text file to the computer, the contents of which included two words - "Gazprom" and "stop" - arranged in random order. After that, the computer died, but not immediately, but with a delay of five minutes. Naturally, it was possible to make a delay for a day, but then we would not have met the time allotted for the demonstration. Employees of "Gazprom" complained about the low level of information security and said that this is not their business, since they are guided by the requirements and rules set by the FSB. The circle closed, it became clear that this monolithic system of "information irresponsibility" could not be broken through. In the more than three years that have passed since then, I have never heard anyone speak of virtualization hardware as a tool to penetrate target systems. Paradox? I don’t think so. The specificity of the topic is that we only learn about failed technologies. We do not know about technologies that have not been discovered, and their authors, of course, are silent. It should be borne in mind that the reliable placement of bookmarks in the BIOS is possible only in the factory. Under operating conditions, this will require focusing on a specific motherboard model, and such options are not very interesting to hackers. They need a mass scale, they work, as they say, "by area". However, there are those who attack aiming, "sniper style". The technology for placing bookmarks in the BIOS, and even with the activation of virtualization hardware, which allows you to effectively hide them, is, of course, a convenient tool for such "snipers". Once they were almost caught, and almost by accident. I think that now it will not be possible to do this, and there is no one to catch, as you probably understood. A long time ago, when personal computers were purchased abroad in batches of several hundred pieces, and not in millions of "circulations", under the auspices of one of the KGB departments, small commercial offices were organized to "search for bookmarks." Now we all understand perfectly well that this was one of the honest ways to take money away, because at that level of support and organization it was possible to find anything, but just not a tab in the composition of chips. But large buyers from the number of state offices and enterprises still had nowhere to go. They paid.
advertising
Today Intel does not even hide the fact that tools for remote PC control are built into the processors and chipsets of modern computer platforms. The highly publicized Intel Active Management Technology (AMT) should help simplify remote system maintenance — diagnostics and recovery — without user intervention. But no one is insured that it is also possible to use the rights of the AMT administrator for malicious purposes and, as it turns out, there is not just a bookmark, there is a whole "mortgage".According to a publication by security expert Damien Zammit, modern Intel chipsets have an embedded local and isolated Intel Management Engine (Intel ME) microcontroller chip. This is a solution with its own firmware that is not available for examination by third-party tools and with full control over the processor, memory and the system as a whole. Moreover, the controller can work with the PC turned off, as long as power is supplied to the memory. Of course, the operating system and utilities will neither sleep nor spiritually know about the controller's activity and will not sound an alarm while it is working with the system and data.
Concern that, given a sufficient technical level of the enemy, there is a danger of performing a hidden modification of any chip. The modified chip will work in critical nodes, and the introduced "Trojan horse" or "hardware backbone" will go unnoticed, undermining the country's defenses at the most fundamental level. For a long time, such a threat remained hypothetical, but an international team of researchers was recently able to implement it at the physical level.
Georg T. Becker from the University of Massachusetts, along with colleagues from Switzerland and Germany, as part of a proof of concept, created two versions of a "hardware-level trojan" that disrupts the operation of a (pseudo) random number generator (PRNG) in the cryptographic block of Intel Ivy processors. Bridge. Cryptographic keys created using the modified PRNG for any encryption system will be easily predictable.
The presence of a hardware tab is in no way determined either by built-in tests specially designed for this, or by an external examination of the processor. How could this have happened? To answer this question, it is necessary to return to the history of the emergence of hardware PRNG and get acquainted with the basic principles of its operation.
When creating cryptographic systems, it is necessary to eliminate the possibility of quick selection of keys. Their length and degree of unpredictability directly affect the number of options that the attacking side would have to sort through. The length can be set directly, but it is much more difficult to achieve uniqueness of key variants and their equal probability. To do this, random numbers are used during key generation.
Currently, it is generally accepted that due to software algorithms alone it is impossible to obtain a truly random stream of numbers with their uniform chaotic distribution over the entire specified set. They will always have a high frequency in some parts of the range and remain somewhat predictable. Therefore, most of the number generators used in practice should be perceived as pseudo-random. They are rarely cryptographically reliable enough.
To reduce the effect of predictability, any number generator needs a reliable source of random seed. Usually, the results of measurements of some chaotic physical processes are used as it. For example, fluctuations in the intensity of light vibrations or the registration of radio frequency noise. It would be technically convenient to use such an element of randomness (and the entire hardware PRNG) in a compact version, and ideally make it built-in.
Intel has been building (pseudo) random number generators into its chips since the late nineties. Previously, their nature was analogous. The random values \u200b\u200bat the output were obtained due to the influence of difficult to predict physical processes - thermal noise and electromagnetic interference. Analog generators were relatively easy to implement as separate blocks, but difficult to integrate into new circuits. As the workflow became smaller, new and lengthy calibration steps were required. In addition, the regular decrease in supply voltage worsened the signal-to-noise ratio in such systems. PRNGs worked constantly and consumed a significant amount of energy, and the speed of their work left much to be desired. These shortcomings imposed restrictions on possible applications.
The idea of \u200b\u200ba (pseudo) random number generator with an all-digital nature has seemed strange, if not absurd, for a long time. After all, the state of any digital circuit is always rigidly deterministic and predictable. How to introduce the necessary element of randomness into it if there are no analog components?
Attempts to create the desired chaos based on digital elements alone have been undertaken by Intel engineers since 2008 and have been crowned with success after a couple of years of research. The work was presented in 2010 at the VLSI Summer Symposium in Honolulu and made a small revolution in modern cryptography. For the first time, a fully digital, fast and energy efficient PRNG has been implemented in a commercial general purpose processor.
Its first working title was Bull Mountain. Then it was renamed to Secure Key. This cryptographic block consists of three basic modules. The first generates a stream of random bits at a relatively slow rate of 3 Gbps. The second evaluates their variance and combines them into blocks of 256 bits, which are used as sources of random seed. After a series of mathematical procedures in the third block, a 128-bit stream of random numbers is generated at a higher rate. On their basis, using the new RdRand instruction, if necessary, random numbers of the required length are created and placed in a specially designated register: 16, 32 or 64 bits, which are eventually transferred to the program that requested them.
Errors in generators of (pseudo) random numbers and their malicious modifications cause a loss of confidence in popular cryptographic products and the very procedure for their certification.
Due to the exceptional importance of PRNGs for any cryptographic system, tests were built into the Secure Key to verify the quality of the generated random numbers, and leading expert groups were involved for certification. The entire unit meets the criteria of ANSI X9.82 and NIST SP 800-90 standards. In addition, it is NIST FIPS 140-2 Level 2 certified.
Until now, most of the work on hardware Trojans has been hypothetical. The researchers proposed additional designs from small logic circuits that had to be added in some way to existing chips. For example, Samuel Talmadge King and his co-authors presented at LEET-08 a version of such a hardware trojan for the central processor that would give full control over the system to a remote attacker. By simply sending a configured UDP packet, one could make any changes on such a computer and gain unlimited access to its memory. However, additional logical circuits are relatively easy to identify by microscopy, not to mention specialized methods for finding such modifications. Becker's group went the other way:
Instead of connecting additional circuitry to the chip, we implemented our hardware level tabs by simply changing the operation of some of the microtransistors already in it. After several attempts, we were able to selectively change the polarity of the dopant and make the desired modifications to the operation of the entire cryptographic unit. Therefore, our family of Trojans has proven to be resistant to most detection methods, including scanning microscopy and comparison with reference chips. "
As a result of the work done, instead of unique numbers with a length of 128 bits, the third Secure Key block began to accumulate sequences in which only 32 bits were different. Cryptographic keys generated on the basis of such pseudo-random numbers are very predictable and can be cracked within a few minutes on an ordinary home computer.
The selective change in the electrical conductivity underlying the hardware tab was implemented in two versions:
- digital post-processing of signals from Intel Secure Key;
- use on a side channel using the Substitution-box method.
The latter method is more versatile and can be applied with minor modifications to other chips.
The ability to use the onboard PRNG via the RdRand instruction first appeared in Intel's Ivy Bridge architecture processors. Intel has written detailed guides for programmers. They describe methods for the optimal implementation of cryptographic algorithms and provide a link to a description of how Secure Key works. For a long time, the efforts of security experts were aimed at finding vulnerabilities in the software part. Perhaps, for the first time, hidden intervention at the hardware level turned out to be a much more dangerous and quite feasible technology.
