Convenient remote controls save system administrators many forces - and at the same time they represent a huge security threat in the event that they cannot be disabled by hardware using a jumper or switch on system board. Block Intel Management Engine 11 in modern Intel platforms represents just such a danger - initially it cannot be disabled and, moreover, some mechanisms of initialization and operation of the processor are tied to it, so a rough deactivation can simply lead to a complete inoperability of the system. The vulnerability lies in the Intel Active Management Technology (AMT) technology and, with a successful attack, allows you to gain full control over the system, which was discussed back in May of this year. But researchers from Positive Technologies .

The IME processor itself is part of the System Hub (PCH) chip. Excluding processor slots PCI Express, all communication between the system and the outside world goes through the PCH, which means that the IME has access to almost all data. Prior to version 11, an attack along this vector was unlikely: the IME processor used its own architecture with the ARC instruction set, about which little was known to third-party developers. But in version 11, the technology was played a bad joke: it was transferred to the x86 architecture, and the modified MINIX was used as the OS, which means that third-party binary code research was greatly simplified: both the architecture and the OS are well documented. Russian researchers Dmitry Sklyarov, Mark Yermolov and Maxim Goryachy managed to decrypt the IME version 11 executable modules and began their thorough study.

Intel AMT technology has a vulnerability score of 9.8 out of 10. Unfortunately, completely disabling IME on modern platforms is not possible for the reason described above - the subsystem is closely related to CPU initialization and startup, as well as power management. But from a flash memory image containing IME modules, you can remove everything superfluous, although it is very difficult to do this, especially in version 11. The me_cleaner project is actively developing, a utility that allows you to remove the common part of the image and leave only the vital necessary components. But let's give a small comparison: if in versions of IME up to 11 (before Skylake) the utility deleted almost everything, leaving about 90 KB of code, then currently it is necessary to save about 650 KB of code - and in some cases the system may turn off after half an hour, since the block The IME goes into recovery mode.

There are moves, however. The aforementioned group of researchers managed to use a development kit provided by Intel itself, which includes the Flash Image Tool utilities for configuring IME settings and the Flash Programming Tool, which works through an on-board SPI controller. Intel does not publish these programs in open access, but finding them on the web is not difficult.

The XML files obtained using this kit were analyzed (they contain the structure of the IME firmware and the 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 it was the name of a high-trust platform program affiliated with the US NSA. Turning this bit on indicated that the system was in Alt Disable Mode. The IME block did not respond to commands and did not respond to inputs from the operating system. There are also a number of more subtle nuances that can be found in the article on Habrahabr.ru, but in new version me_cleaner has already implemented support for most dangerous modules without setting the HAP bit, which puts the IME engine in a "TemporaryDisable" state.

The last modification of me_cleaner leaves even in the 11th version of IME only the RBE, KERNEL, SYSLIB and BUP modules, no code was found in them to enable the IME system itself. In addition to them, you can use the HAP bit to be sure that the utility also knows how to do it. Intel has reviewed the results of 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, they have undergone limited testing, and these configurations are not officially supported by Intel. The company also denies introducing so-called backdoors into its products.

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 very well that it was one of the fair ways withdrawal of money, because at that level of support and organization you could find anything, but not a bookmark as part of the chips. But large buyers from among state offices and enterprises still had nowhere to go. They paid.

advertising

Today, Intel does not even hide the fact that the processors and chipsets of modern computer platforms have built-in tools for remote PC control. Widely advertised Intel technology Active Management Technology (AMT) should help simplify remote system maintenance - diagnostics and recovery - without user intervention. But no one is insured that you can also use AMT administrator rights for malicious purposes, and, as it turns out, there is not just a bookmark, there is a whole "trap".

According to a publication by security expert Damien Zammit, modern Intel chipsets have an integrated local and isolated Intel Management Engine (Intel ME) microcontroller chip. This is a solution with its own firmware, which is not available for study by third-party tools and with the rights of 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 the power is supplied to the memory. Of course, the operating system and utilities will neither sleep nor spirit know about the activity of the controller and will not sound the alarm while it is working with the system and data.

Search for electronic devices for intercepting information using electromagnetic field indicators

COURSE WORK

Specialty "10.02.01 Organization and technology of information security"

Completed by: Shevchenko Konstantin Pavlovich

student group number 342

_______________/_____________/

signature F.I.O.

"____" ___________2016

Checked:

Teacher

_______________/S.V. Lutovinov/

signature F.I.O.

"____" ___________2016

Tomsk 2016

Introduction. 3

Types of bookmarks. four

Acoustic bookmarks. 4

Phone bookmarks. 7

Hardware bookmarks. 8

Electromagnetic field indicators. ten

RF meters. 13

Scanner receivers and spectrum analyzers. fourteen

Hardware-software and special control complexes. 16

Radiation detection system. 17

Means of control of wire lines. eighteen

Nonlinear locators and metal detectors. twenty

Bookmark detection. 21

Conclusion. 22

Literature. 23

Introduction

Information has long ceased to be personal. It has acquired a tangible cost weight, which is clearly determined by the real profit received when using it, or the amount of damage, with varying degrees of probability, caused to the owner of the information. However, the creation of information generates whole line difficult problems. One of these problems is the reliable maintenance of the safety and established status of information circulating and processed in information-computing systems and networks. This problem came into use under the name of the problem of information security.

A special check is a set of engineering and technical measures carried out using control and measuring equipment, including specialized technical means, aimed at preventing interception technical information containing information constituting a state secret, personal, with the help of embedded in protected technical means and products of special electronic stowing devices.

Target term paper: to get acquainted with the basics and means of searching for electronic devices for intercepting information using electromagnetic field indicators in theory and practice.

Types of bookmarks

Acoustic bookmarks are special miniature electronic devices interception of acoustic (speech) information, covertly installed in rooms or machines. Information intercepted by acoustic bookmarks can be transmitted via radio or optical channel, via the power grid alternating current, by telephone line, as well as by the metal structures of buildings, pipes of heating and water supply systems, etc.

Rice. 1. Acoustic radio bookmark

The most widely used are acoustic bookmarks that transmit information over a radio channel. Such devices are often called radio bookmarks. Depending on the propagation medium of acoustic vibrations, radio bookmarks are divided into acoustic radio bookmarks and radio stethoscopes.

Acoustic radio bugs are designed to intercept acoustic signals through a direct acoustic (air) channel of information leakage. The sensitive element in them is, as a rule, an electret microphone.

Rice. 2. Radio stethoscope

The radio stethoscope is designed to intercept acoustic signals propagating along the vibroacoustic (walls, ceilings, floors, water supply, heating, ventilation pipes, etc.) leakage channel. They usually use piezomicrophones or accelerometric sensors as sensitive elements. In order to increase the operating time, these acoustic bookmarks can be equipped with control systems for turning on the radio transmitter from voice, as well as systems remote control. To receive information transmitted by radio bookmarks and radio stethoscopes, scanner receivers and software and hardware control systems are used.

In addition to bookmarks that transmit information over the radio, there are bookmarks in which 220 V power lines are used to transmit information. Such acoustic bookmarks are called network. To intercept information transmitted by network bookmarks, special receivers are used that are connected to the power network within the building.

In practice, it is also possible to use acoustic bookmarks that transmit information through the lines of security and fire alarm systems, as well as telephone lines. The simplest device that transmits information over a telephone line is the so-called "telephone ear" device (Fig. 3).

Rice. 3. Telephone ear TU-2

Phone bookmarks designed to eavesdrop on information transmitted over telephone lines. Usually done in the form separate module or disguised as elements telephone set, telephone plug or socket.

To intercept information in such bookmarks, two methods are used: contact and non-contact methods. With the contact method, information is taken by direct connection to a controlled line. With the non-contact method, information is collected using a miniature inductive sensor, which eliminates the possibility of establishing the fact of eavesdropping on information.

The transfer of information using a telephone bookmark begins at the moment the subscriber picks up the handset.

Rice. 4. Phone bookmark

Hardware bookmarks- these are electronic devices illegally and covertly installed in technical means of processing and transmitting information (computers) in order to ensure information leakage, violation of its integrity or blocking at the right time. Made in the form of standard modules used in computers, with minor modifications. As a rule, they are placed in a computer when assembling a computer by order of an enterprise of interest, as well as during troubleshooting or modifications carried out during a service or warranty period.

Rice. 5. Hardware bookmark

With the help of hardware bookmarks, it is possible to intercept data, for example, I / O data personal computer: monitor image; data entered from the keyboard, sent to the printer, written to internal and external media.

In addition to acoustic, telephone and hardware bookmarks for unauthorized retrieval of information, portable video recorders.

Broadcast from video cameras can be directly recorded on a video recorder, or transmitted over a radio channel using special transmitters. If, in addition to the video image, sound transmission is required, then a microphone is installed together with the video camera. As a rule, video image transmitters are made as a separate unit, while having a small size and weight. But there are cases when they are structurally combined with television cameras (Fig. 5).

Rice. 6. Video transmitter

Video cameras and transmitters are powered either from built-in batteries, while the operating time, as a rule, does not exceed several hours, or from the 220 V mains, while their operation time is practically unlimited.

I am not a professional in the field of information security, my area of ​​interest 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 non-fictional story will highlight the problems associated with virtualization hardware much better than a dry statement of facts. Even before the official announcement of new Intel processors with support for hardware virtualization (in early 2007), I planned to use these chips to create a single computing system based on several servers, which would become a single computing installation with an SMP architecture for the OS and application programs. To do this, it was necessary to write a compact hypervisor with non-standard functionality, main feature which would not be the division of the resources of a single computing installation between different operating systems, but, on the contrary, the union of the resources of several computers into a single complex, which would be controlled by one OS. At the same time, the OS should not have even guessed that it was not dealing with unified system but with multiple servers. Virtualization equipment provided such an opportunity, although it was not originally intended for solving such problems. Actually, a system in which virtualization hardware would be used for high-performance computing has not yet been created, and 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 platform initialization 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. There was no serial equipment with virtualization hardware at that time, however, thanks to cooperation with the Kraftway company, I had access to pre-series samples of processors and motherboards with virtualization support that had not yet been officially released (the so-called samples that Intel kindly provides to its business partners). Therefore, the work began to boil on this "sample" equipment. The layout was assembled, the hyperdriver was written, everything worked as intended. I must say that at that time the virtualization equipment was very "raw", which is why it repeatedly refused to work as written in the documentation. I had to deal with literally every assembler instruction, and write the instructions for the virtualization equipment in machine codes, because then there were no compilers supporting virtualization instructions. I was proud of the results, I felt almost like the master 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 at that time, but the layout did not work. I began to understand and realized that my system hangs when executing hardware virtualization commands. It seemed that they either did not work at all, or worked somehow non-standard. The freeze occurred only while the virtualization hardware was running in real mode, but if my system was started from protected mode after the OS loaded, then everything was fine. Professionals know that in the first revisions, the Intel virtualization hardware did not support the processor in real mode. This required extra layer large enough to emulate virtual x86. Since the hyperdriver was running before the operating system loaded, so that it could fully believe in the new virtual configuration, a small piece of OS boot code was executed in the real mode of the processor. The system was dying just on the emulation handlers real mode in the hyperdriver. At first I thought that somewhere I made a mistake, I didn’t understand something, I 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 colleagues from behind a hillock. The first step was to replace the processors, but it did not help. On motherboards at that time, virtualization hardware was only in the BIOS, where it was initialized when the server was turned on, so I started comparing BIOSes on motherboards (same motherboards with samples) - everything matched up to the byte and number of the BIOS itself. I fell into a stupor and, no longer knowing what to do, applied last resort- "poke method". What I just didn’t do, no longer thinking, but simply combining, and in the end stupidly downloaded the bios from the official Intel website and rewrote them again 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 serial motherboards only worked when I filled them with the same bios taken from the Intel site. So, the reason is still in the motherboards? But their only difference was in the labeling: Assembled Canada was written on the samples, and Assembled China on the production boards. It became clear that boards from China contain additional software modules flashed in the BIOS, but these modules were not seen by standard analysis programs. They, apparently, also worked with virtualization equipment and, accordingly, had the opportunity to hide the true contents of the BIOS. It also became clear why my hyperdriver freezes on these Chinese boards: two software systems simultaneously worked with the same virtualization equipment, which did not allow sharing their resources. I wanted to deal with this malicious bios, and without any ulterior motives about "bookmarks", "backdoors", "undocumented features", it was just an academic interest, and nothing more. I must say that in parallel with the introduction of virtualization hardware, Intel radically updated the chipset. This chipset, which received the number 5000x, is still available 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 produced almost unchanged since 2007 and is used as the base chip for almost all servers in a two-socket version. I downloaded the southbridge datasheet, read the description, and was just blown away. 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 naval unit integrated into the south bridge. The system management unit (SMB) is a means of remote control and monitoring of a computer installation. It is indispensable for large server rooms, where, due to noise, temperature and drafts, it is simply impossible to stay for a long time. The fact that naval units have their own processor and, accordingly, flash memory for its programs, of course, is not new, but until now such a processor and memory were placed on a separate board that was connected to the motherboard: if you want - put it, if you don’t want it - don't put. Now Intel has implemented these components in the south bridge, moreover, 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 to the main network adapters. Further, I learned from the documentation that the programs on the flash chip of the naval unit are encrypted, and a special hardware cryptographic module, also integrated into the south bridge, is used to unpack them. I have not come across such blocks of the Navy before. In order not to be unfounded, I give 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.

The use of foreign cryptographic tools with a key length of more than 40 bits is prohibited in Russia by law, but here you are! - in each Intel server, a cryptomodule with unknown keys 256 bits long. Moreover, these keys were used to encrypt programs embedded in the motherboard chips at the production stage. It turns out that the naval units in Russia on Intel servers that have a 5000x chipset in their composition should be disabled. However, these blocks, on the contrary, are always in working order, even if the computer installation itself is turned off (for the operation of the VMS, the standby voltage is enough, that is, the server power cable plugged into the socket). All this seemed secondary to me at that time, because first I had to find out which of the flash chips contained a software module that worked with virtualization hardware and interfered with my hyperdriver, and I began to experiment with firmware. After reviewing the documentation, I became wary, and when I discovered that the hyperdriver's performance was restored just after flashing the flash microcircuit of the naval unit, I was not even surprised. It was impossible to understand further without special stands, since cryptography completely blocked the possibilities of code reverse for the Navy. I did not find documentation on the internal architecture of this integrated Navy, in the datasheet for the south bridge, Intel described only the interface registers for controlling this unit using standard access methods, resulting in a classic "black box". The totality of the facts was alarming and led to paranoid thoughts in the style of spy detectives. These facts clearly indicated the following:

• In new serial server rooms Intel boards based on the 5000 chipset, there are programs flashed into the flash memory of the BMC unit and executed on the central processor, and these programs work using virtualization equipment CPU.
• Flash memory images from the official Intel website do not contain such software modules, therefore, software modules that interfere with me were illegally flashed into motherboards at the production stage.
• The flash memory of the VMS block contains encrypted program modules that cannot be assembled and uploaded to the flash memory without knowing the encryption keys, therefore, the one who inserted these illegal program modules knew the encryption keys, that is, he actually had access to secret information.

I informed the management of Kraftway about the problem with the firmware of the flash memory of the naval unit and the dubious situation from the point of view of the legislation with new Intel chipsets , to which he received a quite expected answer in the style of "don't mess around, you're interfering with business." I had to calm down, because you can’t really argue against employers. My hands were tied, but "my thoughts, my horses" did not give me peace, it was not clear why these difficulties were and how all this was done. If you have the ability to put your own software in the memory of the naval unit, why do you need all this hassle with the central processor? A reasonable reason could only be that the task being solved required to control the current computing context on the central processor. Obviously, it is impossible to keep track of the information being processed on the main computer system using only a peripheral low-speed processor with a frequency of 60 MHz. Thus, it seems that the task of this illegal system was to retrieve information processed on the main computer installation using virtualization hardware. Of course, it is more convenient to remotely control the entire illegal system from the BMC unit processor, since it has its own independent access to the network adapters on the motherboard and its own MAC and IP addresses. The question "how is it done?" was more academic in nature, because someone managed to create a hypervisor that can share virtualization hardware resources with another hypervisor and does it correctly for all modes except the real mode of the CPU. Now you won’t surprise anyone with such systems, but then, five years ago, they were perceived as a miracle, in addition, the emulation speed was amazing - it was impossible to programmatically emulate a host without significant performance losses. For an explanation, you have to delve a little into the theory. The architecture of Intel and AMD virtualization systems does not imply the presence of several hypervisors on the platform at once, however, the hypervisor launched first can emulate work on real virtualization hardware for hypervisors that are launched after. In this case, all hypervisors launched after the first one run in the emulated host environment. This principle I call "the right of the first night." It can be easily implemented using special handlers in the root host, while the task mode will not change significantly, and the secondary hypervisor hosts will run in the task mode for the root host. The emulation mode is not difficult to organize, but there are problems with performance. Virtualization hardware works primarily with the VMCB (VMCS), host programs constantly access this block, and each such access requires 0.4-0.7 µs. It is almost impossible to hide such software host emulation for an Intel virtualization system, too many virtualization commands will have to be emulated in software through exits to the root host, instead of executing them on real hardware. I'll tell you a little about the differences between virtualization architectures. Hardware virtualization systems from Intel and AMD are completely different from each other. The main architectural difference between these systems is the host mode. On an AMD system, the host runs with virtualization hardware disabled, meaning its programs run on a real processor. Secondary host virtualization on AMD systems only requires virtualization of the VMRUN command (assuming there are no other commands). The work with the control VMCB-block in the AMD architecture occurs through the usual commands for accessing random access memory, which allows you to control only the execution of VMRUN commands using the secondary host and, if necessary, correct the VMCB block before actually entering the task mode. It is still possible to lengthen the event processing cycle twice, and AMD platform such emulation is viable. In the Intel virtualization system, things are much more complicated. To access the VMCB block, special commands VMREAD and VMLOAD are used, which must be virtualized. Typically, host handlers access the fields of the VMCB block dozens, if not hundreds of times, and each such operation needs to be emulated. At the same time, it is noticeable that the speed drops by an order of magnitude, this is very inefficient. It became clear that unknown colleagues used a different, more efficient mechanism for emulation. And hints about which one, I found in the documentation. The Intel host itself is a virtual environment, that is, in fact, in this regard, it does not differ from the task execution environment and is simply controlled by another VMCB (see diagram). In addition, the documentation describes the concept of a "dual monitor" for virtualizing the SMM mode (system management mode), when in fact two hosts are active at once and, therefore, two VMCB blocks, and the host virtualizing the system management mode controls the main host as a task , but only at system management interrupt trigger points. This set of indirect facts suggests that the Intel virtualization hardware probably has a mechanism for controlling multiple secondary hosts managed by the root host, although this mechanism is not described anywhere. Also, this is how my system worked, and I still have no other explanation for the almost imperceptible actions of the root hypervisor. It became even more interesting: it seems that someone had access to these undocumented features and used them in practice. Approximately six months before the end of cooperation with Kraftway, I took the position of a passive observer, nevertheless continuing to regularly launch my system on new batches of serial motherboards from China and new samples. On the samples, everything continued to work stably. When I switched to Chinese boards, more and more miracles arose in the system. It seemed that colleagues from abroad were actively improving the performance of their root hypervisor. The last suspicious batches of boards behaved almost normally, that is, the first launch of my hyperdriver led to a system reboot during OS startup, but all subsequent launches of the hyperdriver and OS went without a hitch. In the end, what I had long expected happened: a new batch of serial motherboards arrived, using which my hyperdriver did not freeze at all. I was already beginning to doubt my paranoid suspicions, but a new incident reinforced them. It should be noted that Intel is actively improving virtualization hardware. If the first revision of the hardware with which I started working was number 7, then the described situation occurred on the 11th revision, that is, the revision was updated twice in about a year (revisions for some reason have only odd numbers). So, on revision number 11, the conditions for exiting to the host according to the state of the task for virtualization equipment have significantly expanded, in accordance with which a new control field was even introduced in the VMCB block. When sample processors appeared with this revision of the virtualization hardware, I wanted to try out new possibilities in practice. I upgraded the hyperdriver with the new features of the 11th revision of the virtualization hardware, installed the sample processor on a serial board from China, in which everything already worked without any problems, and started debugging. The new capabilities of the equipment did not show themselves in any way, and I again fell into prostration, sinning on the sample processor and documentation. After some time, the motherboard was needed for another task, and, having resumed experiments, I rearranged the processors with the 11th revision of the virtualization hardware to the Canadian sample for safety reasons. Imagine my surprise when everything worked on this sample! At first I thought that somewhere I messed up with the serial board, since the new outputs to the host had absolutely nothing to do with the motherboard, this is a purely processor function. To test, I moved the sample processor to a serial board, and everything stopped working again. So, I didn’t mess up anything, and the problem lay in the fact that the motherboard somehow influenced the new capabilities of the processor virtualization hardware. Taking into account my suspicions, the only conclusion was that the illegal root host of colleagues from abroad, flashed into the flash memory of the motherboard, did not know about the new revision of the virtualization hardware. When this hardware, unknown to him, began to work, he stopped correctly passing exits from the state of the task to my secondary host through his own event handler. Already knowing how to deal with this scourge, I uploaded the firmware for the Navy unit from the Intel website to the serial board, turned on the system in the belief that everything would work right away, and again fell into the sediment, as the freezes remained. It was something new. According to my theory, the illegal hypervisor became bold and confident in its invulnerability. Apparently, its authors considered that their brainchild had passed the running-in stage and it was no longer necessary to disguise undebugged software as a BIOS failure. After the function of protecting the initialization code from being overwritten in flash memory was enabled, the bookmark became almost indestructible. I was not sure that I was right, I needed control experiments. I had to invent my own method for detecting a hardware hypervisor. Then, however, it turned out that I had invented the wheel. The method allowed to control the execution time system commands that require mandatory emulation in the hypervisor host. As a timer, I used the cyclic frame counter in the USB controller hardware, and wrote the program for real operation in order to minimize side and uncontrolled interrupts that masked the true execution time of system commands. I did the first test for clean system based on sample motherboards from Canada.
The execution time indicated in the photo is some conditional value, approximately corresponding to the processor cycle. Then I ran the same test on a stock motherboard and confirmed my paranoid assumptions - command execution cycles were significantly lengthened.
That is, in the flash memory of the BMC block of server boards from China, manufactured under the Intel label, there was an undeclared software module installed at the production stage that worked as a hypervisor host. It remains to convince others of this. First of all, I went to the Russian representative of Intel. It was not difficult at all, since the employees of the Russian office often appeared at Kraftway. I told and showed everything, but I was not sure that the technician understood everything. These so-called technical specialists do not differ much from managers in terms of their level of competence. However, he promised to report everything to the leadership. I don’t know if he did it, but there was no response from Intel, everything went like sand. Work at Kraftway was over by that time, and I began new project in an information security firm. The head of this firm, with whom I shared my "discoveries", took my words seriously. In this regard, it was decided to go to the leadership of the Center for Information Protection and Special Communications of the FSB. This structure within the FSB is responsible for 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 security measures for government agencies and commercial firms that process secret and confidential information . The firm I worked for at the time maintained official contacts with the Center to certify and license their commercial projects, so it was quite easy to arrange a meeting at the specialist level. It was assumed that the experts of the Center would report their opinion to the leadership, and if after that the leadership deems it necessary to listen to us, then the next step would be a meeting at a higher level. The meeting took place, I told and showed everything that I managed to find out, then I demonstrated the presence of an illegal software module using examples of boards from Canada and China. By the way, then for the first time I heard the professional term "bookmark", denoting such a module. When the conversation turned to the Navy, misunderstanding appeared in the eyes of colleagues from the Center. I had to conduct an educational program. Along the way, it turned out that they did not even suspect the existence of a special microprocessor in the south bridge with access to the network adapter and the presence of a cryptographic module in the naval unit that violated Russian law. In conclusion, we unexpectedly heard that this threat model has already been investigated, a set of countermeasures is being applied against them, and in general, we are not afraid of bookmarks, since our systems do not have Internet access. Further inquiries did not lead to anything, everything rested on secrecy, like, we are smart and super-literate, but you are not supposed to know anything. However, I strongly doubted their technical literacy, because they simply did not understand most of what I said and showed. They parted on the fact that they would report to their superiors, and they would decide on further actions. A little later, I found out what this "secret method" is for detecting host programs. 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 virtualization commands. Indeed, processor instructions for virtualization equipment 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 chip? How will they scan this code in RAM if these memory areas are protected from viewing by hardware? In general, the result of the first meeting left an unpleasant aftertaste, and I was in the most gloomy mood waiting for 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, not ordinary employees 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 listed the new vulnerabilities of the x86 platform, showed a bookmark and told how to detect it, answered many questions. At the end, they thanked us, said that the topic should be developed within the framework of special research projects, and on this we parted. The euphoria disappeared when information reached us through unofficial channels that they simply did not want to believe us. However, this did not dampen 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 bookmark software module myself. I would not be able to put a bookmark in the flash memory of the Navy, but I could well push it into the main BIOS. I decided to equip the hypervisor with a self-security module for masking in memory and on a flash chip, as well as to block writing to the flash chip where the bookmark code will be placed, after which it will only be possible to remove it by soldering the BIOS and reprogramming it on an external programmer. It only remained to decide on the "malicious" function that the hypervisor should have performed. I remembered the statement of one of the FSB specialists that they were not afraid of bookmarks, since their systems were disconnected from the global network. But information from the outside world must somehow get into these protected local networks, at least through disposable optical discs. Thus, I came to the obvious conclusion and decided to analyze the incoming information flow in a bookmark by means of a hyperdriver in order to implement, so to speak, a doomsday weapon, that is, to use a bookmark to destroy a computing system on an external command, passing it through the input information stream, steganographically. Scan the information flow discreetly, without loss of performance, only virtualization equipment is tough. At what point to scan is also clear: on the I / O buffers of disk systems and the network adapter. Scanning I/O buffers is a trivial task for virtualization hardware. No sooner said than done! Such a hyperdriver with a size of about 20 KB was registered in the BIOS of the motherboard and equipped with a detection protection 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 was received to destroy it. The command itself, for ease of implementation, was hardwired into a text file in the DOC format in the configuration 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, an order 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, almost without hoping for anything, in fact, to clear our conscience, we tried to convey information about the problem to users of information security systems. We contacted Gazprom to inform the company's specialists about modern threats to distributed process control systems. It was possible to organize a meeting with the management of the corporate protection and management service complex systems the security of this corporation. Especially for them, a more visual version of the bookmark with a simplified command interface was prepared. The bookmark was activated after downloading to the computer text file, 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 even for a day, but then we would not have kept within the time allotted for the demonstration. Employees of Gazprom complained about the low level of information security and said that it was none of their business, since they are guided by the requirements and rules established by the FSB. The circle closed, it became clear that this monolithic system of "information irresponsibility" could not be broken. In the three-plus years that have passed since then, I have never heard anyone talk about virtualization hardware as a tool to infiltrate target systems. Paradox? I don't think. The specifics 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 reliable placement of bookmarks in the BIOS is possible only in the factory. In operating conditions, this will have to focus on a specific model of the motherboard, and such options are not very interesting for hackers. They need mass, they work, as they say, "by area." However, there are those who attack aiming, "sniper-like". Technologies for placing bookmarks in the BIOS, and even with the activation of virtualization equipment, which allows you to effectively hide them, are, 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, as you probably understood, there is no one to catch.

Concern that with a sufficient technical level of the enemy, there is a danger of him performing a covert modification of any chip. The modified chip will work in critical nodes, and the introduced "Trojan horse" or "hardware bookmark" will go unnoticed, undermining the country's defense capability 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 of the University of Massachusetts, together with colleagues from Switzerland and Germany, created two versions of a “hardware-level Trojan” that disrupts the operation of the (pseudo) random number generator (PRNG) in the cryptographic block of Intel Ivy architecture processors as part of a proof of concept Bridge. The 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 external examination of the processor. How could this happen? To answer this question, it is necessary to return to the history of the appearance of a hardware PRNG and familiarize yourself with basic principles his works.

When creating cryptographic systems, it is required 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 try. The length can be set directly, but it is much more difficult to achieve the uniqueness of key variants and their equal probability. To do this, random numbers are used during key generation.

At present, it is generally accepted that due to only software algorithms 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 of occurrence in some parts of the range and remain predictable to some extent. Therefore, most of the number generators used in practice should be taken as pseudo-random. They are rarely secure enough in a cryptographic sense.

To reduce the effect of predictability, any number generator needs a reliable source of random seed - 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 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 analog. Random values ​​at the output were obtained due to the influence of hard-to-predict physical processes - thermal noise and electromagnetic interference. Analog oscillators were relatively easy to implement as separate blocks, but difficult to integrate into new circuits. As the process got smaller, new and lengthy calibration steps were required. In addition, a regular decrease in the 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 have limited the possible areas of application.

The idea of ​​a (pseudo)random number generator with an all-digital nature seemed strange, if not absurd, for a long time. After all, any state digital circuit always rigidly determined and predictable. How to introduce the necessary element of randomness into it if there are no analog components?

Attempts to get the desired chaos based only on digital elements have been made by Intel engineers since 2008 and were 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 mass-produced general-purpose processors.

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 seeding. After a series of mathematical procedures in the third block with more high speed a 128-bit stream of random numbers is generated. Based on them, with new instruction RdRand, if necessary, random numbers of the required length are created and placed in a specially allocated register: 16, 32 or 64 bits, which are eventually transferred to the program that requested them.

Errors in (pseudo)random number generators 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 PRNG for any cryptographic system, tests were built into Secure Key to check the quality of generated random numbers, and leading expert groups were involved in certification. The entire block meets the criteria of ANSI X9.82 and NIST SP 800-90. In addition, it is Level 2 certified to NIST FIPS 140-2.

Until now, most of the work on hardware Trojans has been hypothetical. The researchers proposed additional designs of small logical circuits, which should somehow be added to existing chips. For example, Samuel Talmadge King and co-authors presented at the LEET-08 conference a variant of such a hardware Trojan for the central processor, which would provide complete control over the system to a remote attacker. By simply sending a UDP packet configured in a certain way, 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 under microscopy, not to mention specialized methods for searching for such modifications. Becker's group went the other way:

Instead of adding additional circuitry to the chip, we implemented our hardware-level tabs by simply changing the operation of some of the microtransistors already on it. After a number of attempts, we managed to selectively change the polarity of the dopant and introduce the desired modifications into the operation of the entire cryptographic unit. Therefore, our family of Trojans proved 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 differed. The cryptographic keys created on the basis of such pseudo-random numbers are highly predictable and can be cracked within minutes on a typical home computer.

The selective change in electrical conductivity underlying the hardware tab was implemented in two versions:

1. digital post-processing of signals from Intel Secure Key;
2. use on a side channel using the table bit substitution method (Substitution-box).

The latter method is more versatile and can be applied with minor modifications to other chips.

The ability to use the built-in PRNG through the RdRand instruction first appeared in Intel processors Ivy Bridge architecture. Intel has written detailed manuals for programmers. They describe methods for the optimal implementation of cryptographic algorithms and provide a link to a description of the principles of Secure Key operation. For a long time, the efforts of security experts have been focused on 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 in practice.