• Tidak ada hasil yang ditemukan

Can Electronic Equipment from Untrusted Vendors be Verified? Can an Untrusted Vendor Build Trust into

N/A
N/A
Nguyễn Gia Hào

Academic year: 2023

Membagikan "Can Electronic Equipment from Untrusted Vendors be Verified? Can an Untrusted Vendor Build Trust into "

Copied!
123
0
0

Teks penuh

Abstracts are written based on an invitation from a member of the editorial board. The aim of this book is to provide answers to these questions by analyzing the technical state of the art in all relevant areas of expertise.

A New Situation

What Are We Afraid Of?

After the event, there was intense speculation about what had happened, but no real evidence has been presented. The motivation of the equipment vendor to include the unwanted functionality in the Syrian radar is clear.

Huawei and ZTE

It is critical for a modern society to be able to rely on its electronic equipment and infrastructure. Few countries have the ability to design and manufacture the electronic equipment for their critical infrastructure entirely themselves.

Trust in Vendors

If it were easy, we wouldn't need to debate how much we can trust such equipment;. The reliability of electronic equipment is paramount and we cannot choose to design and manufacture every aspect of this equipment ourselves.

Points of Attack

Unfortunately, our need for software updates means that any change in vendor reliability affects the reliability of all devices ever purchased from that vendor. Therefore, when we ask ourselves whether a seller can be trusted, we should ask ourselves if we trust that the seller will remain reliable for the life of the product we are buying.

Trust in Vendors Is Different from Computer Security

When malware is already on the system at the time of purchase, stopping it from entering is pointless. Malicious system actions can be performed anywhere in the technology stack, from low-level hardware to the software that controls the user interface.

Why the Problem Is Important

If the culprit is the seller, then the malware could be in the system from the moment you buy it and therefore there is no point in preventing it from entering later. However, this trust has never been blind, in the sense that the parties had no control over the quality, properties or handling of the goods being traded.

Advice for Readers

Usually, the buyer also has to trust the seller to provide support and security updates for the life of the product. From this position, the idea of ​​trust between the equipment supplier and the buyer of the equipment takes on a very different flavor.

Prisoner ’ s Dilemma

In the latter case, the winning strategy depends on the average attitude of the population. However, from the seller's point of view, there is also a risk associated with the assumption that the seller will never be caught.

Trust and Game Theory

In this case, it's unclear whether we'll ever know if the seller has defected. As for the prisoner's dilemma, this means that we can assume that the buyer will never know whether the seller has crossed or not, and then we can treat the game as one game for all practical purposes.

Trust and Freedom of Choice

Trust, Consequence, and Situation

The level of trust that the person has in the manufacturer of the watch should hardly be a selection criterion. The level of trust required before one chooses a supplier of equipment for such structures is very high and cases where a lack of trust has prevented said suppliers from competing for such contracts are well documented.

Trust and Security

Even if the locks would keep out all burglars, the locksmith could still keep a copy of the key. Even if you have secured your home, this security is still built on the reliability of the locksmith.

Trusted Computing Base; Trust Between Components

Unfortunately, this strategy – while it could be financially successful – misses the heart of the debate. Because of this, the compiler and synthesis tools used for hardware development are part of TCB.

Discussion

The third-party images or other materials in this chapter are included in the Creative Commons license of the chapter, unless otherwise noted in a line of credit accompanying the materials. On its way from my computer in Norway to the mail server I use in the United States, it passes through routers and switches in several countries.

Transistors and Integrated Circuits

From the observable functionality of each device, there are several layers of technology all built on top of each other before we get down to the physical phenomena that allowed us to build the device in the first place. These characteristics have given rise to modern integrated circuits with a number of transistors that today (2017) can run in the multiple billions and operate at a switching speed of multiple gigahertz.1 Already at the level of the transistor we find places where a manufacturer can build in malicious functionality.

Memory and Communication

We argued above that a circuit can be constructed so that it self-destructs on a given input signal. For memory and communication circuits, it is obvious how such input signals can be received.

Processors and Instruction Sets

For a communications circuit, the signal can come from the outside world, while a memory circuit can be designed to self-destruct when a certain sequence of bits is written to or read from memory. However, self-destruct is a very simple form of sabotage that can be verified by an untrusted seller.

Firmware

But if we don't trust the hardware manufacturer, that assumption is completely broken. The vendor may include undocumented computer instructions known only to the vendor and have their execution triggered on a predetermined input signal of the vendor's choosing.

Operating Systems, Device Drivers, Hardware Adaptation

The fact that the operating system is a very complex and large piece of software makes it extremely difficult to fully examine all its parts. As an illustration, it is assumed that most versions of the Windows operating system have several tens of millions of lines of code.

Bytecode Interpreters

The Application on Top

If the operating system is secure, applications are limited to leaking information that is accessible to the user running the application.

Infrastructures and Distributed Systems

On top of the instruction sets, there are several layers of software before we reach the application. This technology stack could easily consist of billions of transistors and millions of lines of software code.

Discussion

Even under these constraints, the job of protecting against dishonest electronic device makers encompasses the physical phenomena underlying the system's transistors through to the software that runs the application's user interface. This technique is said to have long been known to the CIA [5], who allegedly abused Xcode to add malware to iOS applications.

Software Development

Obviously, such code can be part of the source code of the product itself, but can it be put into the compiler without changing the source code of the product. Malicious code can be installed in the compiler tools that developers are instructed to use.

Fig. 4.1 The structure of compiler code and equipment source code that eventually make up the executable running on the equipment
Fig. 4.1 The structure of compiler code and equipment source code that eventually make up the executable running on the equipment

Hardware Development

Security Updates and Maintenance

Discussion

Some of the pioneers in this field had a strong background in mathematics and worked on the mathematical formulation of the limits of computation in the early days of computing. In this chapter, we review and explain some key results on determinism and explain how these results affect the problem of untrustworthy equipment vendors.

G ö del and the Liar ’ s Paradox

The relationship that the concept of decidability has with our problem of supplier confidence should be obvious. This situation again implies that the statement must be true, but not provable.

Turing and the Halting Problem

Roughly, what Gödel did was to replace the statement 'This statement is false' with 'This statement is not provable'. Clearly, if the latter statement is false, it must be provable, which means it must be true.

Decidability of Malicious Behaviour

Using the liar's paradox, we can easily generate absurdities similar to those described above. In the same way as seen before, this is a manifestation of the liar's paradox and the only conclusion we can draw is that P does not exist.

Is There Still Hope?

The proof based on the liar's paradox holds as long as we require that P has no false negatives or false positives. In particular, when looking for vendor-injected malware, we can accept a relatively high ratio of false positives, as long as there are few false negatives.

Where Does This Lead Us?

If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulations or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. The ability to reverse engineer a product has been important for as long as technology has existed.

Application of Reverse Engineering in ICT

The emergence of software reverse engineering as a field in its own right came about largely as a result of the need to analyze malware. The most controversial use of reverse engineering is related to digital rights management (DRM).

Static Code Analysis

Understanding the tools of the industry will help us understand the latest technology. Ultimately, this will help us assess the extent to which it is possible to fully investigate a product purchased from an unreliable dealer.

Disassemblers

Decompilers

Debuggers

Anti-reversing

Decompilers can be confused by machine code that cannot be reconstructed into the high-level language. Debuggers can be beaten by having the program code detect that it is running in debug mode and simply terminate if it finds that it is.

Hardware

Such changes can be detected by the program itself by calculating checksums on parts of its code. If this happens, hardware obfuscation techniques will reach a state where reverse engineering can be made arbitrarily complex, but not theoretically impossible.

Discussion

Depending on the intent of the dishonest seller, the unwanted functionality can be placed anywhere in the product. Kill switches can be placed anywhere in the hundreds of millions of transistors on a given chip.

Malware Classes

The initial infection of the system can be done with a program that needs to be run only once. Ransomware As the name suggests, this is malicious software that allows an attacker to demand a ransom from the system owner.

Signatures and Static Code Analysis

This list of actions that malware can perform covers the most common motives for infecting a system. Other motives are not only possible, but have inspired some of the most spectacular digital attacks known to date.

Encrypted and Oligomorphic Malware

A second approach was to include multiple versions of the decryption loop in the encrypted part of the malware. For each new generation of the virus, an arbitrary decryption loop is chosen so that one single signature will not be able to detect all generations of the malware.

Obfuscation Techniques

An example of the latter is two instructions that push and pop the same variable onto a stack. The semantics of the malware will be the same, but a signature that detects one instance will not necessarily detect the other.

Polymorphic and Metamorphic Malware

Heuristic Approaches

The complexity of classifiers varies greatly, from simple feature occurrence counts to advanced machine learning techniques. Unfortunately, given the flexibility of the code obfuscation techniques described above, this is not very difficult to do [12].

Malicious Hardware

Consequently, a rogue vendor can ensure that malicious code actions are not executed in the time available to the analyzer. The success of this field is one of the most beautiful stories in the tale of computer security.

Figure 9.1 illustrates the structure of the full formal proof process of a piece of code
Figure 9.1 illustrates the structure of the full formal proof process of a piece of code

Speci fi cation-Based Techniques

Discussion

The whole idea behind signature-based malware detection is that it detects a subset of known and previously analyzed malware and this malware is not present on non-infected systems. In recent years, malware detection has been based on a combination of static methods such as those discussed in this chapter and dynamic methods based on observing code execution actions.

Dynamic Properties

Again, the purpose of this chapter is to shed light on the extent to which dynamic malware detection techniques can help us detect the actions of a dishonest equipment supplier. Each time an assign statement is executed, the taint advances to the memory location that has been assigned a new value, if and only if the new value is computed based on the contents of the already compromised memory location.

Unrestricted Execution

Another useful feature that can be extracted through dynamic analysis is how the system processes data. The lowest level of property that can be captured by dynamic analysis is the sequence of machine instructions that the system executes.

Emulator-Based Analysis

Virtual Machines

Evasion Techniques

Analysis

Therefore, the problem is treated in the same way and with techniques from machine learning and artificial intelligence [7,11]. Second, when methods for detecting malicious activity are made public, they are generally easy to circumvent.

Hardware

One is to activate the Trojan by running the test vectors and comparing the responses to the expected responses. However, this observation should not lead to criticism of researchers in the area; rather, it should make us understand the complexity of the problem at hand.

Discussion

Modern malware detection products combine static and dynamic detection in an attempt to overcome the respective weaknesses of the two approaches [7]. Such models are used in design space exploration, quality assurance processes during construction and certification processes.

Overview

If all propositions are true in the given logic, we can conclude that the implementation conforms to the specification. While this is a promising approach, our problem resurfaces with the question of how to build the model of the software.

Speci fi cation

Programming Languages

These updates fix security holes that apparently must have been present in the product purchased before the update was installed. In the case of a black box, we are basically left with testing, a situation discussed in Section 10.8.

Fig. 10.1 The hierarchy of software quality characteristics of Boehm et al. [6]. The edges in the hierarchy denote necessary conditions
Fig. 10.1 The hierarchy of software quality characteristics of Boehm et al. [6]. The edges in the hierarchy denote necessary conditions

Hybrid Programming and Speci fi cation Languages

Semantic Translation

Therefore, later developments attempted to reformulate the deduction rules to form the basis of the algorithmic support for the construction of this part of the test. As stated in the previous section, process algebra arose from the observation that the distinction between specification and implementation seen in Hoare logic creates difficulties when it comes to parallel and distributed systems.

Logics

The reason is that improved execution time is the reason to replace the specification with the implementation in the first place.

Theorem Proving and Model Checking

82 9 Formal methods Model checking has proven to be very useful for both finding bugs and proving the properties of protocols [6]. But for the problem we study in this book, model checking comes at a high price because building a model of a system creates a degree of indirection in the proof systems.

Proof-Carrying Code

Conclusion

The focus of the research in formal methods has been to provide formal verification, find errors or generate cases for testing. Nevertheless, in the search for a solution to our problem, further research in this direction appears as one of the most promising ways forward.

What is Software Quality Management?

Quality assurance for software is therefore different from quality assurance for most other products. The main elements of software quality assurance are the development process, the quality model and the implemented quality management scheme.

Software Development Process

88 10 Software Quality and Quality Management Soon, however, it became clear that software engineering presented its own very specific challenges. Due to the general invisibility of software and the fact that its quality is not affected by the process of producing its copies, software quality assurance is aimed at the production and maintenance phases.

Software Quality Models

A particular trend that has been influential in recent years is the inclusion of insights into human psychology and interaction patterns in the software development process. This has led to the development of so-called agile approaches [12], among which Scrum[25] is particularly popular and successful.

Software Quality Management

Software Quality Metrics

Thus, it is included in all modern quality models and has been the subject of significant academic scrutiny [15]. If a system vendor has included a hidden backdoor in the code, the number of backdoors included in total matters little.

Standards

With one mistake all certainty could be lost and the second mistake therefore adds little to the situation. Nor is certifying an organization or piece of software to the same standards.

Common Criteria (ISO/IEC 15408)

Structuring existing methods into a framework will not solve our problem unless there is a solution in the methods themselves. In the following sections, we cover the basic methods that make up the Common Criteria assurance levels.

Software Testing

The other part of the solution is replacing or somehow dealing with misbehaving equipment. The strength of the approach is that it holds the promise of addressing all sides of the problem.

Veri fi cation Through Formal Methods

Code Review

As argued in Chapter 4, a review of the source code alone gives a dishonest equipment vendor full opportunity to include malicious code through the compiler or other development tools. One way to deal with this problem is to perform a code review on only parts of the software product.

Discussion

23] estimate that a full analysis of the Windows code base would take between 35 and 350 man-years. In the current state of the art, formal methods are not suitable for the program sizes we need, code review is error-prone and too time-consuming to be watertight, and testing has limited value due to the problem of hitting the right test vector that lures it malicious behavior.

Overview

Until full and unconditional trust prevails in the world, we will have to build and maintain digital infrastructures made up of equipment we don't fully trust and equipment made up of modules we don't fully trust. In the real world, we deal with people and organizations we don't trust by trying to contain them.

Partial Failures and Fault Models

For example, it is very difficult to implement a module so that it guarantees compliance with the fail-stop model. Unfortunately, nuclear broadcasts, like fail-stop modules, are easy to describe but generally impossible to implement in a real system.

Erlang: A Programming Language Supporting

Despite these shortcomings, the study of error models and rough implementations of protocols that handle them have resulted in extremely complex, robust, and flexible real-world systems. For us, this means that one of the essential mechanisms for keeping modules unreliable—replacing misbehaving pieces of software at runtime—has been studied for a long time, and that we can consider this problem solved in a considerable measure.

Microservices: An Architecture Model Supporting

It addresses the detection of malicious behavior through module size and observability, addresses the need for alternatives that can be trusted due to heterogeneity, and, like Erlang, allows easy replacement of untrusted modules. The apparent simplicity of the microservices model hides the fact that the size of a complex system reappears in the number of microservices needed to implement it [6].

Hardware Containment

Discussion

The inclusion of untrusted modules is the most promising approach we have to our problem, firstly, because all the mechanisms developed in the last decades for fault-tolerant systems are well suited to our need to perform the inclusion, and secondly, because the detection of misbehaving components does not have to come from ICT technology itself. In this book we asked the following question: What if one or more of the suppliers of the core components of an information and communication technology (ICT) system is dishonest.

Summary of Findings

We provided an overview of the classes of tools used for reverse engineering hardware and software in Chapter 6. In the realm of formal methods, which we discuss in Chapter 9, we have a plethora of logic systems for programs and inference systems that is healthy and complete.

The Way Forward

Encryption

It is therefore necessary to encourage the development, exploitation and dissemination of strong encryption techniques, which will be an important component of the solution to the problem of untrusted equipment. If you can't completely trust the people who built the encryption equipment in all the complexity we described in Chapter 4, then encryption methods offer nothing.

Formal Methods

Therefore, the field of research has resulted in numerous methods that provide a solid foundation for trust even in our case, even when communication may leak and even in the presence of attempted man-in-the-middle attacks. Second, while encryption promises to create protection against threats such as eavesdropping and man-in-the-middle attacks, it does not address the problem of remote control switches.

Heterogeneity and Containment

While the development chain from an algorithmic description of the hardware to gate-level descriptions can be framed by formal methods, the actual production of the chip cannot. Unlike other conceivable approaches, there are no major parts of the problem that we can predetermine as impossible to treat.

Concluding Remarks

Gambar

Fig. 3.1 Schematic overview of a distributed system. Each device builds instruction sets from physical phenomena through the hardware layers of transistors, logic gates, and integrated circuits.
Fig. 4.1 The structure of compiler code and equipment source code that eventually make up the executable running on the equipment
Figure 4.2 shows a schematic of an integrated electronic product and parts of the production line leading up to it
Fig. 5.1 A Turing machine. Based on the state of the state machine and the symbol on the tape, Ω decides the symbol to be written, Δ decides how the tape should be moved, and Π decides the new state of the machine
+3

Referensi

Dokumen terkait

Model pembelajaran Concept Sentence yang dimaksud dalam penelitian ini adalah model pembelajaran yang diterapkan dalam kegiatan pembelajaran menelaah struktur, kebahasaan dan