Original Date: April, 2016<\/p>\n
A clear technical definition of the term backdoor has never reached wide consensus in the computing community. In this paper, I present a three-prong test to determine if a mechanism is a backdoor: \u201cintent\u201d, \u201cconsent\u201d, and \u201caccess\u201d; all three tests must be satisfied in order for a mechanism to meet the definition of a backdoor. This three-prong test may be applied to software, firmware, and even hardware mechanisms in any computing environment that establish a security boundary, either explicitly or implicitly. These tests, as I will explain, take more complex issues such as disclosure and authorization into account.<\/p>\n
The technical definition I present is rigid enough to identify the taxonomy that backdoors share in common, but is also flexible enough to allow for valid arguments and discussion.<\/p>\n
<\/p>\n
Since the early 1980s[1], backdoors and vulnerabilities in computer systems have intrigued many in the computing world and the government, and have both influenced and been influenced by popular culture. Shortly after the movie Wargames<\/em> was released, Ronald Reagan discussed the plot, which revolved around a backdoor in a defense computer system, with members of Congress and the Joint Chiefs of Staff[2], which led to research into the government\u2019s own risk assessments. Before the Internet was largely in place globally, computers at Lawrence Berkeley National Laboratory were compromised by an unknown vulnerability in the popular Emacs editor[3], the story of which led to a New York Times bestseller. Since the 1980s, and with the now global scale of the Internet, remote access trojans (RATs), root kits, and numerous other types of backdoors have been discovered from some of the world\u2019s largest data breaches[4], and have made it into popular culture such as the CSI: Cyber television series, movies, and books. All of these events have included what has been referred to as a backdoor, but without any clear definition to test the validity of that statement.<\/p>\n While backdoors have become a significant concern in today\u2019s computing infrastructure, the lack of a clear definition of a backdoor has led the media (and some members of the computing community) to misuse or abuse the word. System vulnerabilities that are clearly not backdoors are often reported as such in many media news articles[5][6], helping to spread confusion among the general public. This has the capacity to cause not only a disconnect with non-technical readers, but can also engender distrust, misplaced attribution, and even panic.<\/p>\n By misappropriating the use of the term backdoor, media and\/or the entertainment industry can incite the panic that all computer systems are as vulnerable and open to attack as the fictional NORAD defense center in Wargames, and that physical safety is always subject to imminent danger due to such widespread vulnerability. Modern day paranoid has led to many conspiracy articles about power grids, dam computers, and other SCADA systems, painting a bleak picture of numerous doomsday scenarios[10]. While such systems are susceptible to real world attacks, with the help of the media and a little fiction, the public\u2019s fears can escalate beyond a healthy concern for security into paranoid delusions leading to stockpiling weapons, food, and even building underground bunkers. While backdoors are not necessarily the root cause of all of this paranoia, the attribution and conspiracy undertones of the word can help to fuel them.<\/p>\n In addition to public panic due to cyber threat \u201cfan fiction\u201d, the lack of a clear technical definition of a backdoor stands to affect technical analysis and possibly attribution of newly discovered implants in computing devices, which has become increasingly regular. By defining a backdoor, the technical community has a framework by which it can identify, analyze, and attribute new weaknesses as they are discovered.<\/p>\n On a legal front, privacy legislation is anticipated in Congress, and pending legal cases already exist within the court system in which a technical definition of backdoor would be beneficial. Without a clear definition, these proceedings pose the risk of misinformation in criminal prosecution, search warrants, warrants of assistance, secret court proceedings, and proposed legislation – all by preventing a duly appointed legal body from adequately understanding the concept.<\/p>\n In February 2016, the Federal Bureau of Investigation sought an order under the All Writs Act to force Apple Inc. to assist them in bypassing the security mechanisms of their own firmware in a terrorist investigation. Throughout proceedings and Congressional hearings to follow, the term backdoor had been strongly used by both sides to describe the FBI\u2019s order, as well as different scenarios describing future orders or proposed legislation. It is crucial, then, that there be an accepted definition of the term as the very definition of backdoor stands to influence justice and legislation on a national, and possibly worldwide stage. Any future attempts at a legal definition of a backdoor must clearly begin with a technical definition, one of which is presented here.<\/p>\n Some attempts have been made to define backdoor, however all fall short of being both specific enough to cover the intentional and subversive nature of backdoors, and general enough to avoid covering mechanisms that the computing community does not consider a backdoor.<\/p>\n The Oxford Dictionary defines \u201cback door\u201d as \u201ca feature or defect of a computer system that allows surreptitious unauthorized access to data\u201d[13]. This definition makes several incorrect technical assumptions. First, by labeling the backdoor as either a feature or defect<\/em>, the definition makes two incorrect assumptions about the mechanism itself: namely, that it is either designed to improve functionality (a feature), or that any unintentional vulnerability in a system could be considered a backdoor. Either falls short of what I propose as a definition, which rests somewhere in between: the mechanism is not a feature, but an intentionally placed component that is not disclosed to the user, and not the result of a programming error; otherwise any computer vulnerability could be considered a backdoor. The definition also fails to sufficiently cover the purpose of the backdoor, implying that its purpose is only about access to data. There are many backdoors into system that do not provide access to data whatsoever, but rather surrender control of a system to an actor. There are many backdoors placed in security boundary mechanisms that do not protect data. The definition fails to acknowledge such backdoors.<\/p>\n The Linux Information project (LINFO) defines \u201cbackdoor\u201d as \u201cany hidden method for obtaining remote access to a computer or other system\u201d[14]. This definition fails to sufficiently identify a backdoor as a specific mechanism within the software, but rather defines it as a method, suggesting that using any technique to obtain remote access should be considered a backdoor. This is too general, then, and could consider anything from hacking methods to social engineering, as a backdoor. It also allows worms, viruses, exploits, or other means to gain unauthorized access a backdoor, even though many in the computing community would not share that opinion. The second part of the definition requires that remote access be a mandatory requirement for a backdoor, however this paper will demonstrate that backdoors can exist for purposes including local (non-remote) access, or even access by a different user on the same machine. In this paper, I argue that it is the actor<\/em> and not the origin of access that matters. Lastly, this definition is so broad that it would suggest that a software update mechanism (such as the kinds distributed with Linux distributions themselves) or other similar mechanisms could constitute backdoors.<\/p>\n Aside from generalized definitions, it is surprising that no academic papers could be found that specifically attempted to define the term. There are countless papers in which backdoors are documented, and their taxonomy analyzed, however no clear definition of backdoor was found that could be applied to a general component of a computer system. It would seem that for decades, the computing community at large has taken a \u201cknow it when I see it\u201d approach to the term, without ever accepting a clear definition or test.<\/p>\n While backdoors have become increasingly complex and vary in design over time, all backdoors share the same basic taxonomy. They affect security mechanisms (more specifically, boundary mechanisms) in the following ways:<\/p>\n The purpose of the three-prong test in this paper is to provide a basis for technical argument: to be able to effectively argue that a component within a security boundary mechanism constitutes a backdoor, or does not constitute a backdoor, and support that argument with consistent facts.<\/p>\n Essentially, this framework is designed to enable one to point at something, in a technical context, and argue, \u201cthis is a backdoor, and here are my facts to support that argument\u201d, while also enabling someone else to argue, \u201cno it isn\u2019t, and here are my supporting arguments\u201d, with the expectation that after thorough analysis, consensus may be achieved.<\/p>\n Throughout this paper, the term mechanism<\/em> is used to describe a boundary enforcement mechanism (security mechanism) that is being evaluated. A mechanism (or security mechanism) can be any piece of software, firmware, or hardware that establishes, either explicitly or implicitly, a security boundary. For example, an authentication mechanism explicitly establishes a security boundary by controlling user access. A software update mechanism implicitly establishes a security boundary by means of code control; that is, controlling the code introduced into a computer based on the user contract<\/em>, which I will explain in depth. An encrypted channel establishes an implied security boundary by controlling who, or what, can communicate over a privileged channel of communication. All of these are referred to as security mechanisms<\/em> throughout this paper.<\/p>\n When evaluating a mechanism, components of that mechanism may be explored; for example, an authentication mechanism with a component that allows \u201cgolden key\u201d access. In this context, the mechanism is said to be \u201cbackdoored\u201d if the component itself satisfies the requirements of a backdoor. Here, the malicious component, a mechanism in and of itself, is the overall subject of the evaluation within the context of the computer, however it must be explored in the context of the larger security mechanism.<\/p>\n Throughout this paper, the term owner<\/em> or computer\u2019s owner<\/em> is referenced. Because ownership is complex, this term is intended to mean one who has entitlements and authorization to control access on a computer. This is sufficient to address complex ownership models such as employer owned equipment.<\/p>\n This section identifies three specific requirements a security mechanism must satisfy in order to meet the definition of a backdoor, and proposes three crucial questions that must be satisfied to meet these requirements.<\/p>\n The intent<\/em> requirement determines whether or not the actions performed by the security mechanism, as intended by its manufacturer, were adequately disclosed to the owner of the computer. Typically, a backdoor can exhibit malicious behavior related to subverting a security boundary<\/em> that is expected by the user; the requirement allows for this to satisfy the intent of the manufacturer, however also leaves the requirement broad enough so as to accommodate other mechanisms that violate a security boundary that may not be as straightforward, such as the software controls in a software update service.<\/p>\n \u201c<\/em>Does the mechanism behave in a way that subverts purposes disclosed to the computer owner?\u201d<\/em><\/p>\n The concept of intent<\/em> plays closely to user trust and perception. In other words, does the mechanism perform\u00a0only<\/em> the tasks that the user expects it to perform (or support tasks that the user expects the larger components to perform), or does it, by design, subvert these purposes? If the mechanism can exhibit undisclosed behavior that is contrary to the intents disclosed to the user by the manufacturer, then this satisfies the intent<\/em> requirement.<\/p>\n Consider the code controls of a typical software update mechanism. The intent, as disclosed by the manufacturer, is to prevent unauthorized updates. Disclosure by the manufacturer about what types of updates are authorized establishes a user contract.<\/p>\n A user contract<\/em>, as I refer to herein, is an abstract construct whereby the manufacturer and the user have developed a mutual understanding and expectation of the intention and proper function of a mechanism. This construct allows the user to manage consent, which will be discussed in the next section. For example, the manufacturer will state that the purpose of software updates are to fix bugs and introduce new code into the system that the user would not find objectionable, according to the manufacturer\u2019s privacy policies and end-user agreement.<\/p>\n An example of a user contract can be considered with the example of an authentication mechanism inside of a router that provides maintenance access with a \u201cgolden key\u201d password. Here, the intent of the manufacturer for the authentication module was disclosed to the user as a function understood to allow only authorized users<\/em> into the system (understood to mean having a password that matches a known password created by an administrator)<\/em>. By allowing for a maintenance password to bypass the administrator\u2019s user list, the mechanism has subverted its original purpose in providing a security boundary, and violated the user contract.<\/p>\n Such discussions about intent can quickly become complicated. A manufacturer\u2019s intent can change over time, and with that the user contract<\/em> must be re-evaluated. For example, consider a software update that updates itself and adds a licensing component that the user may find objectionable. This new purpose must be expressed to the user prior to an update; otherwise the mechanism can be seen as having broken its user contract.<\/p>\n When new functionality is added to an existing user contract, additional disclosure is required in order to modify the user contract; this is frequently seen in practice. For example, release notes are displayed or published by software manufacturers prior to a software update. If intent has changed, the disclosed changes can continue to revise the user contract by again implying consent through disclosure, so long as the user continues to have an informed decision about the mechanism running on their computer. Software that initially obtained the user\u2019s consent, but then revised its intent without disclosure to the user has violated the user contract, and therefore invalidated consent.<\/p>\n Lastly, consider the term intent<\/em>, as well as the term subvert<\/em>, incorporated into the definition. The term subvert takes into account a certain level of intentionality by design. This framework does not attempt to address the matter of negligence, but rather leaves that up to existing legal remedies to explore. It does, however leave open the argument that the manufacturer, for the purpose of exploitation, can leave a mechanism intentionally vulnerable; this is difficult to demonstrate in practice.<\/p>\n Whether or not the manufacturer\u2019s intent for the mechanism is clear can determine whether or not stated purposes were subverted<\/em>. There is enough freedom here to use other arguments to suggest intent through negligence, but also enough depth to this to ensure that a mechanism is not a backdoor simply because it is vulnerable. Some such arguments may overall be semantic ones, rather than technical ones.<\/p>\n The second requirement to determine if a mechanism meets the definition of a backdoor is a test of consent<\/em>. This determines whether or not the owner of the computer has authorized the mechanism in question, based on the user contract established by means of disclosing their intent.<\/p>\n \u201cIs the mechanism, or are subcomponents of the mechanism, active on a computer without the consent of the computer\u2019s owner?\u201d<\/em><\/p>\n This requirement provides enough room to be sufficiently satisfied in cases where consent is compelled (therefore, not truly consent), as well as cases where consent cannot be revoked (such as a service that cannot be turned off, which is also not consent).<\/p>\n Consider the controls of our automatic software update service from the prior section. Software update services typically behave in such a way as their capabilities rest in the hands of owner consent, however consent of the controls themselves are more or less implied. By activating software updates, the user is granting consent to the underlying security mechanisms with the pretense that they will behave according to their stated intent; in other words, they will only permit authorized code to be introduced into the system.<\/p>\n By enabling software updates, the owner implicitly grants consent to the underlying security mechanisms to place controls on the kind of software that is installed, but only to the extent of their disclosed intent<\/em>. As long as these security controls are performing their disclosed tasks (in accordance with the user contract), such a mechanism would not<\/em> satisfy this requirement to meet the definition of a backdoor, because it has the user\u2019s consent to control the introduction of code accordingly.<\/p>\n In contrast, backdoors are mechanisms that are active without consent (e.g. that is, \u201cunauthorized\u201d), or cannot be disabled by means made available to the owner. For example, consider a subcomponent of the software update mechanisms that permits unauthorized software to be introduced into the system. The owner did not authorize this subcomponent (since it was not part of the user contract), and therefore did not grant consent for it to be active on the system \u2013 this satisfies the consent<\/em> requirement to meet the definition of a backdoor. On the other hand, if the security mechanism was compromised (\u201chacked\u201d), then it does not meet the consent <\/em>requirement to meet the definition of a backdoor, because it was still running with the user\u2019s consent. In this case, it is a compromised mechanism, but not a backdoor. This concept of compromised mechanisms will be explored in more detail throughout the paper. The intention of the manufacturer, which ultimately effects the user contract, plays a key role in determining the difference between the two.<\/p>\n Consider the following examples that would satisfy the consent<\/em> requirement to meet the definition of a backdoor:<\/p>\n As demonstrated by these examples, consent is inherently tied to the manufacturer\u2019s intent<\/em>, and ultimately the concept of a user contract established between the manufacturer and the user.<\/p>\n The access<\/em> requirement determines two factors:<\/p>\n \u201cIs the mechanism under the control of an undisclosed actor?\u201d<\/em><\/p>\n The access<\/em> requirement establishes both whether the mechanism is under control<\/em> (that is, can be controlled or accessed at all by anyone other than users explicitly authorized by the computer owner), and<\/em> whether or not it can be controlled or accessed by any\u00a0undisclosed actors, <\/em>such as unknown third parties. Here, the term undisclosed actors<\/em> means anyone other than the computer owner, any users he or she has authorized to access the mechanism, and any disclosed external actors, such as the software manufacturer (delivering updates).<\/p>\n This is probably the most crucial requirement of all three tests because it contrasts the difference between a backdoor and other types of malicious code, such as malware, trojans, viruses, and adware. All of these can be backdoors, if they include a command-and-control (C2) component, however not every instance of these are in fact backdoors. A destructive piece of malware, for example, that is not controllable by the malware\u2019s creator, is not a backdoor because it does not satisfy this requirement. A botnet payload that is controlled by a bot-master, however, does satisfy this requirement.<\/p>\n A piece of software that queues up information for future access is considered to be accessible by an actor. For example, a piece of malware that caches personal data, to be sent in batch, would satisfy this requirement towards meeting the definition of a backdoor.<\/p>\n This requirement also covers mechanisms involving access by a third party by means of proxy, for example a piece of ransomware in which the actor controls the software through decryption keys entered into the software by the computer owner. Such a mechanism satisfies this requirement towards meeting the definition of a backdoor.<\/p>\n This test is where the rubber meets the road when discussing government backdoors, such as the concept of pushing malicious software through an update mechanism without the computer owner\u2019s knowledge. A software update mechanism, when behaving healthy, may not appear to satisfy the requirements of a backdoor, however if the mechanism can be controlled by a third party (either directly, or indirectly via court order) to subvert its stated intent, then it has violated the user contract, invalidated consent, and satisfies the definition of a backdoor.<\/p>\n Does a legitimate software update service that is attacked and used to push malware to the computer system constitute a backdoor? On a technical level, no, because the intentions of the software have not changed (unless malicious intent by the manufacturer can be demonstrated). There is an argument to be made, however, that the service has effectively been backdoored<\/em>; i.e. \u201ca hacker turned the service into a backdoor\u201d, or, \u201ca hacker backdoored the service\u201d, however this is not a technical argument, only a semantic one. I make no attempt in this paper to define the proper use of backdoor<\/em> as a verb.<\/p>\n This section will examine a number of thought exercises, applying the three-prong test to various scenarios and expanding on the different ways it may be applied. These examples are intended for guidance only, and not to demand a specific technical conclusion about the examples used. The reader has the freedom to make counter-arguments and to test their interpretation of the three-prong test to arrive at their own conclusion.<\/p>\n Considering recent \u201cbackdoor\u201d legislation as it pertains to a legislated backdoor into end-user computer systems, legislation to allow the government to compel a manufacturer to install malicious software through a software update mechanism alone would not necessarily constitute a backdoor, unless this information was withheld from customers<\/em>. If a manufacturer were to fully disclose\u00a0that specific government agencies had control over a software update mechanism, and that the mechanism could install software whose intent <\/em>was to introduce code deemed to be objectionable to the user, then the mechanism no longer satisfies the intent<\/em> or the access<\/em> prongs of the test.<\/p>\n In other words, in order for the government to legislate a mechanism that would no longer meet the definition of a backdoor, they must disclose to the owner that the government can install functionality through auto-update (the third prong), or disclose that functionality that can introduce code deemed objectionable by the owner (the second prong). If the user chooses to still update their software, then this is not a backdoor because it\u2019s been disclosed, and either its intent or its origins have been fully stated. It is, in fact, much worse than a backdoor at this point; it is a surveillance tool<\/em> and should be treated as such in law.<\/p>\n Some may wish to use a definition such as \u201cgovernment backdoor\u201d, implying a disclosed form of a backdoor, however this is a semantic argument and not a technical one; it also does little justice to describe the civil rights issues that are raised by compelling such a surveillance tool.<\/p>\n Consider the following more realistic scenario, however. If the government were to misrepresent or hide the intent and the origins of their capabilities to subvert the auto-update software controls, ordering this functionality in secret, then this has not<\/em> been disclosed to the user, and pushing malware or spyware (under the direction of an actor undisclosed to the user) would meet the definition of a backdoor, invalidating consent given by means of a user contract. This will be explored in the next section of this paper.<\/p>\n The construction of the three-prong test provides enough flexibility for technical arguments to be made of what constitutes consent and disclosure on a national stage. Because this framework has led us to such arguments (which are out of scope), the framework itself has done its job in providing a construct in which these arguments can be explored.<\/p>\n In today\u2019s legal landscape, secret court orders are a possibility. In such scenarios, we are no longer discussing disclosed actors or intent, but rather secret orders such as those going through a FISA court, such as section 702 orders or secret orders under the All Writs Act. In these cases, our hypothetical software update service could unwittingly\u00a0become<\/em> a backdoor if the government chose to quietly control it without any disclosure to the user.<\/p>\n In the same way, for the manufacturer to be ordered to keep such capabilities a secret would be to turn the manufacturer into an arm of government for the express intent of creating a backdoor<\/em>, and the manufacturer could be considered partially liable for the consequences of doing so.\u00a0Those that control the mechanism dictate the intent, and so if the government is partially in control of the mechanism, then their intentions must become part of the overall test. In such a case, the functionality of the software would likely subvert the intent disclosed to the user. Consent would similarly become invalidated, resulting in a software update mechanism that qualifies as a backdoor by definition.<\/p>\n Shortly after the release of research in 2014[7], Apple\u2019s file relay <\/em>service became the subject of debate among the information security community, and whether or not it constituted a backdoor.<\/p>\n File Relay was an Apple service that ran without the user\u2019s knowledge on millions of iOS devices. The service was a mechanism that bypassed the\u00a0backup password\u00a0<\/em>encryption on versions of iOS 7 and below, and was accessible by either using an existing pair record from a desktop machine, or by creating one by pairing an unlocked device on-the-fly. It was\u00a0not a backdoor into the device\u2019s operating system, but rather I argued that it was an\u00a0encryption backdoor;<\/em>\u00a0it provided a way to bypass a critical\u00a0security boundary against data theft, and subverted the backup password\u2019s own stated purpose: to allow paired devices to be better secured against data theft.<\/p>\n Of course, this doesn’t mean it was nefarious, or intended for objectionable\u00a0purposes\u00a0(although that didn’t stop law enforcement from taking full advantage of it); Apple later claimed its purpose was for collecting diagnostics information. Applying the three-prong test to this service, my arguments are as follows.<\/p>\n \u201cDoes the mechanism behave in a way that subverts purposes as disclosed to the computer owner?\u201d<\/em><\/p>\n The actual use for the file relay service was\u00a0unclear at the time, until Apple came out publicly stating its intention as a diagnostics tool, however none of its functionality was – at the time – disclosed to the user. It was also not\u00a0known that by allowing a device to pair with a desktop machine, this enabled a\u00a0capability to bypass backup encryption.<\/p>\n My counter-argument was\u00a0that a diagnostic service constantly running on the device was arguably not within the scope of the user contract.\u00a0All\u00a0other known diagnostic services in iOS were on-demand (with user consent), whereas file relay was \u201calways on\u201d. Its purposes included defeating a security mechanism that was explicitly provided to the user. Once the research\u00a0made the existence of this service known to the average user, Apple promptly disabled it in all future firmware updates, demonstrating that the user did not consider this part of Apple\u2019s stated intent. Future versions of iOS have the service disabled by default, and iOS is more secure for it today, much to the credit of Apple for quickly addressing it.<\/p>\n \u201cIs the mechanism, or are subcomponents of the mechanism, active on a computer without the consent of the computer\u2019s owner?\u201d<\/em><\/p>\n The existence of the file relay service was not disclosed to any user, and it was active on millions of\u00a0iOS devices without the user\u2019s consent. The user had no way to disable this mechanism, even after research made its existence known, so it could not operate with user consent.<\/p>\n \u201cIs the mechanism under the control of an undisclosed actor?\u201d<\/em><\/p>\n The mechanism was subject to access by anyone with a pair record copied off of one of the user’s machines, or by generating one on-the-fly from the user interface; once paired, it could be accessed across a WiFi network. It did not require authentication by the manufacturer to be used (such as a special certificate), or any other means of access control.<\/p>\n Remaining undisclosed to the user, I argued that ignorance of this capability modified the user\u2019s perception of pairing relationships and screen lock policies, since the user believed that backup encryption protected a paired device from dumping the device\u2019s content. This may have caused some users to be more lax with which devices they chose to pair with (such as community devices, work devices, or family and friend devices), or screen access.<\/p>\n The service was available to any USB or WiFi connection capable of using or generating a pair record. I argued that by defeating the security mechanism explicitly given to the user (backup encryption), file relay extended what would have been more restrictive access practices through pairing, as well as physical access, where a pair record could be created on-the-fly.<\/p>\n So was file relay\u00a0<\/em>a backdoor? It failed the\u00a0consent<\/em>\u00a0test and, in my opinion,\u00a0the access<\/em>\u00a0test. The real question is whether or not the mechanism satisfied the\u00a0intent<\/em> test, and this is where many such technical conversations will end up. To Apple, it likely was\u00a0not their intention to create a mechanism that subverts their own security; this could have easily been a programming oversight, with bypassing backup encryption an unintended side effect. The intent of the security boundary is what matters most here, and the security boundary was access control to user content\u00a0via backup encryption. The real question is whether or not defeating backup encryption was intentional (even if only intended for internal use), or a design error.<\/p>\n To law enforcement, file relay was exploited as if it were a backdoor, and\u00a0this capability was integrated\u00a0– without Apple’s participation\u00a0– into\u00a0a number of commercial forensic tools to bypass user encryption for prosecuting crimes \u2013 a capability the user was not expecting from Apple. Under this definition, however, the manufacturer\u2019s intent is what\u2019s important in satisfying this requirements, and not the third party’s misuse.<\/p>\n Depending on how you interpret the\u00a0intent<\/em> test, its broader intention to subvert encryption<\/em>\u00a0could make it a backdoor for engineering purposes, or its more narrow intention as a poorly designed diagnostics tool<\/em> could conclude that it was just a bad day of\u00a0engineering. One might argue that law enforcement forensics tools backdoored <\/em>the file relay service, which would make it a backdoor belonging to such product manufacturers, and not Apple. That is more of a semantic argument than a technical one.<\/p>\n The Clipper chip was a cipher chipset developed and endorsed by the United States National Security Agency[8]. The chip itself was designed to provide a key escrow enabling law enforcement the capability of decrypting any communication as a third party to any messages sent through the chip. It is considered by most to be the quintessential definition of a \u201cbackdoor\u201d.<\/p>\n The three-prong test I have proposed here analyzes implementation<\/em> in the context of a mechanism inside a computer. There are, therefore, different contexts to analyze the Clipper chip in. The standalone chip could be considered, as it incorporates a subcomponent that provides a \u201cbackdoor\u201d key escrow through use of a Law Enforcement Access Field, however it is much more important to have a discussion about the Clipper chip in the context of a computer (such as the AT&T TSD-3600) it has been installed in, in order to correctly apply the three-prong test. Since the three-prong test deals specifically with the context of a mechanism inside a computer, the chip itself (the mechanism) arguably does not constitute a computer on its own. We will analyze the chip from the perspective of an installation inside the AT&T TSD-3600.<\/p>\n The Clipper chip was designed as a drop-in replacement for the DES [NBS77] cryptographic chipset[8]. The only product that it made it into was the AT&T TSD-3600 Telephone Security Device. While the capabilities of the chip had become made known to the public, the AT&T TSD-3600 itself was never sold to the public. It was, however, used internally inside various government agencies.<\/p>\n The user manual itself only made vague disclaimers about cryptanalytic attacks and did not forwardly state in any way that one intent<\/em> of the device included surveillance capabilities[9]. It also did not make any mention of the government, or any agencies, as actors that had control or access to the device[9].<\/p>\n In the analysis to follow, consider the three-prong test as applying from the perspective of a government employee who has been given a TSD-3600 to use, or a hypothetical end consumer (such as a CEO) who has purchased the device, had it been available for public consumption.<\/p>\n It\u2019s important to note that any peripheral disclosure outside of that by the manufacturer is irrelevant to our purposes. Simply because the Clipper chip was known, by way of media, to allow for government surveillance does not satisfy the demands of disclosure in general; this, however, is a technical position to be argued outside of the scope of the backdoor test. For our purposes here, we will consider external factors such as the media irrelevant to disclosure.<\/p>\n \u201cDoes the mechanism behave in a way that subverts purposes as disclosed to the computer owner?\u201d<\/em><\/p>\n Disclosed purposes, according to the TSD-3600 manual[9] did not include a surveillance mechanism for law enforcement that bypassed the user privacy boundary. The manual made no attempt to notify the user of this capability, and there is nothing on record to demonstrate that AT&T made this capability known in any other way to the end-user. The intent<\/em> requirement is satisfied.<\/p>\n \u201cIs the mechanism, or are subcomponents of the mechanism, active on a computer without the consent of the computer\u2019s owner?\u201d<\/em><\/p>\n In the case of the TSD-3600, the user did not give consent for the Clipper\u2019s LEAF mechanism to be active. The user also does not have any ability to disable it. Therefore, the consent<\/em> requirement is satisfied.<\/p>\n \u201cIs the mechanism under the control of an undisclosed actor?\u201d<\/em><\/p>\n The mechanism was under the control (or accessible) by an undisclosed actor (namely any government agency capable of sending the correct signal to the device). The access<\/em> requirement is satisfied.<\/p>\n The TSD-3600 incorporated a chip designed to give surveillance capabilities to the government. While the chip itself, out of context, is merely a surveillance-backdoor \u201ckit\u201d of sorts, its undisclosed use in a product demonstrates its implementation as a backdoor. The \u201cmechanism\u201d in question here is the LEAF mechanism that subverts the user privacy contract.<\/p>\n One might argue that court proceedings that garnered attention on the national stage may constitute disclosure. In this scenario, a government employee who actively used the TSD-3600 being fully aware of its surveillance capabilities was not necessarily using what they considered a backdoored product, but to them it may better fit the definition of an internal surveillance device.<\/p>\n Had the implementation been different, it is possible that the Clipper could conceivably be used in ways that would not constitute a backdoor, but rather a disclosed surveillance tool, for much the same reasons that modern Mobile Device Management is not considered a backdoor. For example, if AT&T had published in the manual that the surveillance capabilities of the Clipper existed in the device, or made known that government actors had control\/access to the cipher routines inside the TSD-3600, then the user would have been informed of the intent of the unit, and could have made an informed decision to use a different solution.<\/p>\n On the other hand, had legislation passed that mandated Clipper\u2019s use in all<\/em> secure telephony products, then the user arguably would have no way to revoke consent of the mechanism. Disclosure would then determine whether the Clipper was a secret backdoor, or a mass surveillance tool without user consent, had its purpose been plainly disclosed to all end-users. I will reiterate, the civil rights atrocity for a government to compel the use of a mass surveillance tool on its citizens goes far beyond the malicious intent of a backdoor, and should be looked upon with more serious consequences than a backdoor.<\/p>\n In this section, we examine two of the most destructive worms in history: My Doom and Code Red II. \u00a0The My Doom worm affected one million machines and reported damages of $38 billion. Code Red II affected one million machines also, and reported damages of $2.75 billion[11]. One of these two worms\u2019 mechanisms will satisfy the definition of a backdoor, while one will not.<\/p>\n \u201cDoes the mechanism behave in a way that subverts purposes disclosed to the computer owner?\u201d<\/em><\/p>\n The My Doom payload was included in an email attachment that subverted the user\u2019s expectations of being an attachment containing a copy of an undelivered message; it had not established a user contract of any kind, and delivered its payload by means of deception. It clearly satisfies this requirement for the definition of a backdoor.<\/p>\n The Code Red worm was not disclosed to the user, and therefore it could not have formed a user contract of any kind with the user. It clearly satisfies this requirement for the definition of a backdoor.<\/p>\n \u201cIs the mechanism, or are subcomponents of the mechanism, active on a computer without the consent of the computer\u2019s owner?\u201d<\/em><\/p>\n The My Doom worm was transmitted via email, masquerading as a mail delivery error message. When the user clicked on the included attachment, the worm executed and resent the worm to all email addresses found in the user\u2019s address book and other files. Here, different arguments about consent can be made. One may argue that the user granted consent by executing the file. On the other hand, one may also argue that the user never intended to execute a file, but open a mail attachment. The latter argument suggests consent was contingent upon their understanding of the intent of the attachment, which turned out to be misrepresented, and therefore consent was not given.<\/p>\n Most would defer to the latter argument as the most valid, however the requirement is flexible enough in that more complex cases involving consent may be effectively argued on both sides. For the purposes of this paper, we shall conclude that it satisfies this requirement for the definition of a backdoor.<\/p>\n The Code Red worm affected machines running Microsoft IIS web server. The worm spread by exploiting buffer-overflow vulnerabilities, using a long buffer of characters followed by exploit code. The Code Red worm did not obtain user consent, and had no interaction with the user; it invited itself into the computer system and executed without any access being granted to it. It clearly satisfies this requirement for the definition of a backdoor.<\/p>\n \u201cIs the mechanism under the control of an undisclosed actor?\u201d<\/em><\/p>\n The purpose of the My Doom worm was believed to have been to launch a distributed denial-of-service attack against SCO Group by flooding the host www.sco.com with traffic. This functionality was baked into the worm, and variants of the worm analyzed, for the purposes of this paper, did not subject the computer to any kind of remote access by a hacker or other actor. Because the worm was completely self-contained, and could not be controlled by any outside factors, the My Doom worm does not<\/em> satisfy the access<\/em> requirement for the definition of a backdoor, and therefore does not satisfy the definition of a backdoor.<\/p>\n The first strains of Code Red were self-contained, however the Code Red II variant installed a mechanism allowing a remote attacker to control the infected computer[12]. This remote access mechanism satisfies the access<\/em> requirement for the definition of a backdoor, and therefore with all three tests satisfied, Code Red II includes mechanisms that fall under the definition of a backdoor.<\/p>\n This requirement is also satisfied by download mechanisms in other worms as well. For example, the ILOVEYOU worm downloaded an executable from the Internet, which ran on infected computers. By changing this executable, one could effectively argue that the attacker had access to infected computers by means of the remote code.<\/p>\n If you take these three prongs and parse them into a single statement, the result is a reasonable technical definition of a backdoor:\u00a0<\/em><\/p>\n A backdoor is a component of a security boundary mechanism, in which the component is active on a computer system without consent of the computer\u2019s owner, performs functions that subvert purposes disclosed to the computer\u2019s owner, and is under the control of an undisclosed actor.<\/em>\u00a0<\/em><\/p>\n With this definition, a mechanism can be said to be backdoored if it contains a component that is a backdoor.<\/p>\n It is the opinion of the author that this is sufficiently specific enough not to be misused. It is not so\u00a0broad that it could describe\u00a0every component of a computer system as\u00a0a backdoor: non-purposeful software components fall under the\u00a0intent<\/em> disclosed to the user as well as informed or implied consent<\/em>, and fall under normal operation of the software. Such services are also not under control<\/em> of any party, but autonomous components running on the system (such as a task scheduling service).<\/p>\n The wording is also specific enough to apply to purposeful code that is intentionally performing tasks in violation of its user contract, but also under the control of an actor. This definition provides a solid construct but also enough room to allow for interpretation and counter arguments.<\/p>\n Defining a mechanism that has been presented in many forms is no easy task, and there may never be an entirely perfect black and white definition. This paper has described the taxonomy of backdoors so as to address their commonalities in a way that provides an adequate technical structure to analyze virtually any security boundary mechanism of a computer. A good definition of a backdoor must be able to contrast a backdoor from other classes of malware or legitimate security mechanisms, and we have done so here successfully. Only time and exposure to a number of technical challenges will determine the efficacy of this three-prong test, however applying it to numerous examples has thus far demonstrated it to be robust enough for consideration within the community.<\/p>\n Special thanks to peer reviewers Dino Dai Zovi and Wesley McGrew, whose insight helped add definition to these concepts.<\/p>\n [1] Wargames (June 3, 1983), Motion Picture. MGM Pictures.<\/p>\n [2] Brown, Scott (July 21, 2008). “WarGames: A Look Back at the Film That Turned Geeks and Phreaks Into Stars”. Wired.<\/p>\n [3] Stoll, Cliff (September 13, 2005). \u201cThe Cuckoo\u2019s Egg: Tracking a Spy Through the Maze of Computer Espionage\u201d.<\/p>\n [4] Zetter, Kim (December 23, 2015). \u201cThis Year\u2019s 11 Biggest Hacks\u201d. Wired.<\/p>\n [5] Haselton, Todd (February 7, 2014). \u201cTarget Hackers Used HVAC Credentials for Backdoor Access\u201d. Techno Buffalo.<\/p>\n [6] Ryge, Leif (February 27, 2016). \u201cMost software already has a \u201cgolden key\u201d backdoor: the system update\u201d. ArsTechnica.<\/p>\n [7] Zdziarski, Jonathan (January 26, 2014). \u201cIdentifying Backdoors, Attack Points, and Surveillance Mechanisms in iOS Devices\u201d. International Journal of Digital Forensics and Incident Response.<\/p>\n [8] Blaze, Matt (August 20, 1994). \u201cProtocol Failure in the Escrowed Encryption Standard\u201d<\/p>\n [9] AT&T (September 30, 1992). \u201cAT&T TSD User\u2019s Manual Telephone Security Device Model 3600\u201d. Archived at http:\/\/www.beatriceco.com\/bti\/porticus\/bell\/pdf\/bsp\/106919921_att_tsd_3600_users_manual_09_30_92.pdf<\/p>\n [10] National Geographic. \u201cDoomsday Preppers\u201d. Television series.<\/p>\n [11] Pudwell, Sam (October 24, 2015). \u201cThe most destructive computer viruses of all time\u201d<\/p>\n [12] CERT (August 6, 2001). \u201cCode Red II: Another Worm Exploiting Buffer Overflow in IIS Indexing Service DLL\u201d.<\/p>\n [13] Oxford Dictionary. Definition 1.1.<\/p>\n [14] Linux Information Project (LINFO). Definition. Archived from http:\/\/www.linfo.org\/backdoor.html.<\/p>\n","protected":false},"excerpt":{"rendered":" Original Date: April, 2016<\/p>\n A clear technical definition of the term backdoor has never reached wide consensus in the computing community. In this paper, I present a three-prong test to determine if a mechanism is a backdoor: \u201cintent\u201d, \u201cconsent\u201d, and \u201caccess\u201d; all three tests must be satisfied in order for a mechanism to meet the definition of a backdoor. This three-prong test may be applied to software, firmware, and even hardware mechanisms in any computing environment that establish a security boundary, either explicitly or implicitly. These tests, as I will explain, take more complex issues such as disclosure and authorization into account.<\/p>\n The technical definition I present is rigid enough to identify the taxonomy that backdoors share in common, but is also flexible enough to allow for valid arguments and discussion.<\/p>\n1.0.1 Need for a Definition<\/h2>\n
1.0.2 Prior Attempts at Definitions<\/h2>\n
1.0.3 General Taxonomy<\/h2>\n
\n
1.1\u00a0\u00a0\u00a0 Purpose<\/h1>\n
1.2\u00a0\u00a0\u00a0 Definitions<\/h1>\n
2.0\u00a0\u00a0\u00a0 Three-Prong Test<\/h1>\n
2.1\u00a0\u00a0\u00a0 Intent<\/h1>\n
2.1.1 Subverted versus exploited<\/h2>\n
2.2\u00a0\u00a0\u00a0 Consent<\/h1>\n
\n
\n
\n
2.3\u00a0\u00a0\u00a0 Access<\/h1>\n
\n
2.4\u00a0\u00a0\u00a0 Liability<\/h1>\n
3.0\u00a0\u00a0\u00a0 Three-Prong Test Thought Examples<\/h1>\n
3.1 Three-Prong Test Applied to Legislation<\/h1>\n
3.2\u00a0\u00a0\u00a0 Three-Prong Test Applied to Secret Court Orders<\/h1>\n
3.3\u00a0\u00a0\u00a0 Three-Prong Test Applied to Apple File Relay<\/h1>\n
3.3.1 Intent<\/h2>\n
3.3.2 Consent<\/h2>\n
3.3.3 Access<\/h2>\n
3.3.4 Discussion<\/h2>\n
3.4\u00a0\u00a0\u00a0 Three-Prong Test Applied to Clipper chip<\/h1>\n
3.4.1 Background<\/h2>\n
3.4.2 Intent<\/h2>\n
3.4.3 Consent<\/h2>\n
3.4.4 Access<\/h2>\n
3.4.5 Analysis<\/h2>\n
3.5\u00a0\u00a0\u00a0 Three-Prong Test Applied to Computer Worms<\/h1>\n
3.5.1 Intent<\/h2>\n
3.5.2 Consent<\/h2>\n
3.5.3 Access<\/h2>\n
4.0\u00a0\u00a0\u00a0 Technical Definition of a Backdoor<\/h1>\n
5.0\u00a0\u00a0\u00a0 Conclusions<\/h1>\n
6.0\u00a0\u00a0\u00a0 Acknowledgments<\/h1>\n
Citations<\/h1>\n