Security in Embedded Systems:
`Design Challenges
`
`SRIVATHS RAVI and ANAND RAGHUNATHAN
`NEC Laboratories America
`PAUL KOCHER
`Cryptography Research
`and
`SUNIL HATTANGADY
`Texas Instruments Inc.
`
`Many modern electronic systems—including personal computers, PDAs, cell phones, network
`routers, smart cards, and networked sensors to name a few—need to access, store, manipulate, or
`communicate sensitive information, making security a serious concern in their design. Embedded
`systems, which account for a wide range of products from the electronics, semiconductor, telecom-
`munications, and networking industries, face some of the most demanding security concerns—on
`the one hand, they are often highly resource constrained, while on the other hand, they frequently
`need to operate in physically insecure environments.
`Security has been the subject of intensive research in the context of general-purpose computing
`and communications systems. However, security is often misconstrued by embedded system design-
`ers as the addition of features, such as specific cryptographic algorithms and security protocols, to
`the system. In reality, it is a new dimension that designers should consider throughout the design
`process, along with other metrics such as cost, performance, and power.
`The challenges unique to embedded systems require new approaches to security covering all as-
`pects of embedded system design from architecture to implementation. Security processing, which
`refers to the computations that must be performed in a system for the purpose of security, can
`easily overwhelm the computational capabilities of processors in both low- and high-end embedded
`systems. This challenge, which we refer to as the “security processing gap,” is compounded by in-
`creases in the amounts of data manipulated and the data rates that need to be achieved. Equally
`daunting is the “battery gap” in battery-powered embedded systems, which is caused by the dispar-
`ity between rapidly increasing energy requirements for secure operation and slow improvements
`in battery technology. The final challenge is the “assurance gap,” which relates to the gap between
`functional security measures (e.g., security services, protocols, and their constituent cryptographic
`algorithms) and actual secure implementations. This paper provides an introduction to the chal-
`lenges involved in secure embedded system design, discusses recent advances in addressing them,
`and identifies opportunities for future research.
`
`Authors’ addresses: S. Ravi and A. Raghunathan, NEC Laboratories America, Princeton, NJ;
`email: {sravi,anand}@nec-labs.com; P. Kocher, Cryptography Research, San Francisco, CA; email:
`paul@cryptography.com; Sunil Hattangady, Texas Instruments Inc., Dallas, TX; email: sunil@ti.
`com.
`Permission to make digital or hard copies of part or all of this work for personal or classroom use is
`granted without fee provided that copies are not made or distributed for profit or direct commercial
`advantage and that copies show this notice on the first page or initial screen of a display along
`with the full citation. Copyrights for components of this work owned by others than ACM must be
`honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers,
`to redistribute to lists, or to use any component of this work in other works requires prior specific
`permission and/or a fee. Permissions may be requested from Publications Dept., ACM, Inc., 1515
`Broadway, New York, NY 10036 USA, fax: +1 (212) 869-0481, or permissions@acm.org.
`C(cid:1) 2004 ACM 1539-9087/04/0800-0461 $5.00
`
`ACM Transactions on Embedded Computing Systems, Vol. 3, No. 3, August 2004, Pages 461–491.
`
`MOBILEIRON, INC. - EXHIBIT 1010
`Page 001
`
`

`

`462
`
`•
`
`S. Ravi et al.
`
`Categories and Subject Descriptors: C.0 [Computer Systems Organization]: General—System
`architectures; C.2.0 [Computer Systems Organization]: Computer-Communication Networks—
`General (Security and protection); C.3 [Computer Systems Organization]: Special-purpose and
`application-based systems—Real-time and Embedded Systems; C.5.3 [Computer Systems Or-
`ganization]: Computer Systems Implementaion—VLSI Systems; D.4.6 [Software]: Operating
`Systems—Security and Protection; E.3 [Data]: Data encryption; K.6.5 [Computing Milieux]:
`Management of Computing and Information Systems—Security and Protection
`General Terms: Security, Design
`Additional Key Words and Phrases: Embedded systems, security, architecture, hardware design,
`processing requirements, battery life, security protocols, cryptographic algorithms, encryption, de-
`cryption, authentication, security attacks, tamper resistance
`
`1. INTRODUCTION
`Today, an increasing number of embedded systems need to deal with security
`in one form or another—from low-end systems such as wireless handsets, net-
`worked sensors, and smart cards, to high-end systems such as network routers,
`gateways, firewalls, and storage and web servers. Technological advances that
`have spurred the development of these electronic systems have also ushered
`in seemingly parallel trends in the sophistication of attacks they face. It has
`been observed that the cost of insecurity in electronic systems can be very
`high. A recent computer crime and security survey [Computer Security Insti-
`tute] from the Computer Security Institute (CSI) and Federal Bureau of In-
`vestigation (FBI) revealed that just 223 organizations sampled from various
`industry sectors had lost hundreds of millions of dollars due to computer crime.
`Figure 1(a) summarizes the costs from various security attacks including theft
`of proprietary information, financial fraud, virus attack, and denial of service.
`Other estimates include a staggering figure of nearly $1 billion in productivity
`loss due to the “I Love You” virus attack [Counterpane]. With an increasing pro-
`liferation of such attacks, it is not surprising that inadequate security is becom-
`ing a bottleneck to the adoption of next-generation data applications and ser-
`vices. For example, in the mobile appliance world, a recent survey [ePaynews]
`revealed that nearly 52% of cell phone users and 47% of PDA users feel that se-
`curity is the single largest concern preventing the adoption of mobile commerce
`(see Figure 1(b)).
`With the evolution of the Internet, information and communications secu-
`rity has gained significant attention [World Wide Web Consortium 1998; U.S.
`Department of Commerce 1999]. A wide variety of challenging security con-
`cerns must be addressed, including data confidentiality and integrity, authen-
`tication, privacy, denial of service, nonrepudiation, and digital content protec-
`tion. Various security protocols and standards such as WEP [IEEE Standard
`802.11], WTLS [WAP 2002], IPSec [IPSec], and SSL [SSL] are used today
`to secure a range of data services and applications. While security protocols
`and cryptographic algorithms address security considerations from a “func-
`tional” perspective, many embedded systems are constrained by the environ-
`ments they operate in, and by the resources they possess. For such systems,
`there are several factors that are moving security considerations from being
`an afterthought into a mainstream system (hardware/software) design issue.
`
`ACM Transactions on Embedded Computing Systems, Vol. 3, No. 3, August 2004.
`
`MOBILEIRON, INC. - EXHIBIT 1010
`Page 002
`
`

`

`Source; 2002 CSI/FBI Computer Crime and Security Survey (223 organizations)
`
`System Penetration -
`
`Virus -
`
`Theftof Proprietary Info. - - - - - - - - - - - - (cid:173)
`Denial of Service -
`
`Financial Fraud - - - - - - - - (cid:173)
`Unauthorized Insider Access Iii
`
`0
`
`20
`
`40
`
`60
`
`80
`
`100 120 140
`
`160 180
`
`Reported Losses (in millions of dollars)
`
`Security in Embedded Systems
`
`•
`
`463
`
`Never heard
`
`Don't understand
`
`User Experience
`
`Security Concerns
`
`i■PDAsl
`~
`
`(31 1')
`(301')
`
`(47%)
`(521..)
`
`0
`
`60
`40
`20
`Note: Users could indicate multiple concerns,
`hence percentages do not add up to 100%
`
`(a)
`
`(b)
`
`(a) The cost of insecurity (source: [Computer Security Institute]) and (b) factors preventing
`Fig. 1.
`the adoption of mobile commerce (source: [ePaynews]).
`
`For example:
`
`r The processing capabilities of many embedded systems are easily over-
`whelmed by the computational demands of security processing, leading to
`failures in sustaining required data rates or number of connections.
`r Battery-driven systems and small form-factor devices such as PDAs, cell
`phones, and networked sensors are often severely resource constrained. It
`is challenging to implement security in the face of limited battery capacities,
`limited memory, and so on.
`r An ever increasing range of attack techniques for breaking security, such as
`software, physical, and side-channel attacks, require that the system be se-
`cure even when it can be logically or physically accessed by malicious entities.
`Countermeasures to these attacks need to be built in during system design.
`
`This paper presents an overview of the challenges in the area of secure em-
`bedded system design. Section 2 introduces the reader to various security con-
`cerns in embedded systems. Section 3 provides a brief overview of basic security
`concepts. Section 4 describes the design challenges that arise from various em-
`bedded system security requirements. Sections 5 and 6 examine some of these
`challenges in detail. Section 5 analyzes the performance, battery life, and flex-
`ibility issues associated with security processing in embedded systems, while
`Section 6 provides an overview of the various threats possible to an embedded
`system. Section 7 presents case studies that depict how advanced architectures
`can be used to address some of these challenges. Section 8 concludes with a
`brief look ahead into the secure embedded system design roadmap.
`
`2. SECURITY REQUIREMENTS OF EMBEDDED SYSTEMS
`Embedded systems often provide critical functions that could be sabotaged by
`malicious entities. Before discussing the common security requirements of em-
`bedded systems, it is important to note that there are many entities involved in
`a typical embedded system design, manufacturing, and usage chain. Security
`requirements vary depending on whose perspective we consider.
`For example, let us consider a state-of-the-art cellular handset that is capable
`of wireless voice, multimedia, and data communications. Figure 2 illustrates
`
`ACM Transactions on Embedded Computing Systems, Vol. 3, No. 3, August 2004.
`
`MOBILEIRON, INC. - EXHIBIT 1010
`Page 003
`
`

`

`464
`
`•
`
`S. Ravi et al.
`
`· Privacy & Integrity o
`personal data
`· Fraudulent calls &
`transactions
`· Loss / theft
`· Secure execution of
`downloaded SW
`• Content security.
`digital rights
`mono ement
`re end-to-end
`Ions
`otion
`
`End user
`
`Content provider
`
`Application
`Service
`provider
`Service
`provider
`Handset
`Monufocturer
`HW/SW
`Providers
`
`Fig. 2. Security requirements for a cell phone.
`
`User
`
`Secure
`network
`access
`
`content
`
`communications
`
`Fig. 3. Common security requirements of embedded systems.
`
`security requirements from the viewpoint of the provider of HW/SW compo-
`nents inside the cell phone (e.g., baseband processor, operating system), the
`cell phone manufacturer, the cellular service provider, the application service
`provider (e.g., mobile banking service), the content provider (e.g., music or
`video), and the end user of the cell phone. The end user’s primary concerns may
`include the security of personal data stored and communicated by the cell phone,
`while the content provider’s primary concern may be copy protection of the mul-
`timedia content delivered to the cell phone, and the cell phone manufacturer
`might additionally be concerned with the secrecy of proprietary firmware that
`resides within the cell phone. For each of these cases, the set of untrusted (poten-
`tially malicious) entities can also vary. For example, from the perspective of the
`content provider, the end user of the cell phone may be an untrusted entity.
`While this section outlines broad security requirements typical of embedded
`systems, the security model for each embedded system will dictate the combi-
`nation of requirements that apply.
`Figure 3 lists the typical security requirements seen across a wide range of
`embedded systems, which are described as follows:
`r User identification refers to the process of validating users before allowing
`them to use the system.
`
`ACM Transactions on Embedded Computing Systems, Vol. 3, No. 3, August 2004.
`
`MOBILEIRON, INC. - EXHIBIT 1010
`Page 004
`
`

`

`Security in Embedded Systems
`
`•
`
`465
`
`r Secure network access provides a network connection or service access only
`if the device is authorized.
`r Secure communications functions include authenticating communicating
`peers, ensuring confidentiality and integrity of communicated data, prevent-
`ing repudiation of a communication transaction, and protecting the identity
`of communicating entities.
`r Secure storage mandates confidentiality and integrity of sensitive informa-
`tion stored in the system.
`r Content security enforces the usage restrictions of the digital content stored
`or accessed by the system.
`r Availability ensures that the system can perform its intended function and
`service legitimate users at all times, without being disrupted by denial-of-
`service attacks.
`
`3. BASIC SECURITY CONCEPTS
`Several functional security primitives have been proposed in the context of net-
`work security. These include various cryptographic algorithms used for encrypt-
`ing and decrypting data, and for checking the integrity of data. Broadly, cryp-
`tographic algorithms can be classified into three classes—symmetric ciphers,
`asymmetric ciphers, and hashing algorithms, which are briefly described below
`(for a detailed introduction to cryptography, we refer the reader to Stallings
`[1998] and Schneier [1996]).
`
`r Symmetric ciphers require the sender and receiver to use the same secret key
`to encrypt and decrypt data. They are typically used for ensuring confiden-
`tiality of data, and can be chosen from two classes—block and stream ciphers.
`Block ciphers operate on similar-sized blocks of plaintext (original data) and
`ciphertext (encrypted data). Examples of block ciphers include DES, 3DES,
`AES, and so on. Stream ciphers such as RC4 convert a plaintext to ciphertext
`one bit (or byte) at a time. For both classes of symmetric ciphers, encryption
`or decryption then proceeds through a repeated sequence (rounds) of mathe-
`matical computations. For example, block ciphers such as 3DES, IDEA, and
`AES use operations such as permutations and substitutions.
`r Asymmetric ciphers (also called public-key algorithms), on the other hand,
`use a private (secret) key for decryption, and a related public (nonsecret)
`key for encryption or verification. They are typically used in security proto-
`cols for verifying certificates that identify communicating entities, generating
`and verifying digital signatures, and for exchanging symmetric cipher keys.
`These algorithms rely on the use of computationally intensive mathematical
`functions, such as modular exponentiation, for encryption and decryption.
`RSA, Diffie–Hellman, and so on are examples of asymmetric ciphers.
`r Hashing algorithms such as MD5 and SHA provide ways of mapping mes-
`sages (with or without a key) into a fixed-length value, thereby providing “sig-
`natures” for messages. Thus, integrity checks can be performed on communi-
`cated messages by (a) having the sender “securely sending” the actual hash
`value of a message along with the message itself, (b) allowing the receiver to
`
`ACM Transactions on Embedded Computing Systems, Vol. 3, No. 3, August 2004.
`
`MOBILEIRON, INC. - EXHIBIT 1010
`Page 005
`
`

`

`466
`
`•
`
`S. Ravi et al.
`
`compute the hash value of the received message, and (c) comparing the two
`signatures to verify message integrity.
`
`Security solutions to meet the various security requirements outlined in
`Section 2 typically rely on the aforementioned cryptographic primitives, or on
`security mechanisms that use a combination of these primitives in a specific
`manner (e.g., security protocols). Various security technologies and mechanisms
`have been designed around these cryptographic algorithms in order to provide
`specific security services. For example:
`
`r Security protocols provide ways of ensuring secure communication channels
`to and from the embedded system. IPSec [IPSec] and SSL [SSL] are popu-
`lar examples of security protocols, widely used for Virtual Private Networks
`(VPNs) and secure web transactions, respectively (we will be examining se-
`curity protocols in greater detail in Section 5).
`r Digital certificates provide ways of associating identity with an entity, while
`biometric technologies [Reid 2003] such as fingerprint recognition and voice
`recognition aid in end-user authentication. Digital signatures, which func-
`tion as the electronic equivalent of handwritten signatures, can be used to
`authenticate the source of data as well as verify its identity.
`r Digital Rights Management
`(DRM) protocols,
`such as OpenIPMP
`[OpenIPMP], MPEG [MPEG], ISMA [ISMA], and MOSES [MOSES], provide
`secure frameworks for protecting application content against unauthorized
`use.
`r Secure storage and secure execution require that the architecture of the sys-
`tem be tailored for security considerations. Simple examples include the
`use of hardware to monitor bus transactions and block illegal accesses to
`protected areas in the memory [Discretix], authentication of firmware that
`executes on the system, application isolation to preserve the privacy and
`integrity of code and data associated with a given application or process
`[Lie et al. 2000], HW/SW techniques to preserve the privacy and integrity
`of data throughout the memory hierarchy [Suh et al. 2003], execution of en-
`crypted code [Best 1981; Kuhn 1997], and so on.
`
`4. SECURE EMBEDDED SYSTEM DESIGN CHALLENGES
`Designers of a large and increasing number of embedded systems need to sup-
`port various security solutions in order to deal with one or more of the security
`requirements described earlier. These requirements present significant bottle-
`necks during the embedded system design process, which are briefly described
`below:
`
`r Processing Gap: Existing embedded system architectures are not capable of
`keeping up with the computational demands of security processing, due to in-
`creasing data rates and complexity of security protocols. These shortcomings
`are most felt in systems that need to process very high data rates or a large
`number of transactions (e.g., network routers, firewalls, and web servers),
`and in systems with modest processing and memory resources (e.g., PDAs,
`
`ACM Transactions on Embedded Computing Systems, Vol. 3, No. 3, August 2004.
`
`MOBILEIRON, INC. - EXHIBIT 1010
`Page 006
`
`

`

`Security in Embedded Systems
`
`•
`
`467
`
`wireless handsets, and smartcards). In this paper, we will examine the two
`sides of the processing gap issue (requirements and availability) and study
`various solutions proposed to address this mismatch.
`r Battery Gap: The energy consumption overheads of supporting security on
`battery-constrained embedded systems are very high. Slow growth rates in
`battery capacities (5–8% per year) are easily outpaced by the increasing en-
`ergy requirements of security processing, leading to a battery gap. Various
`studies [Carman et al. 2000; Perrig et al. 2002; Potlapally et al. 2003] show
`that the widening battery gap would require designers to make energy-aware
`design choices (such as optimized security protocols, custom security hard-
`ware, and so on) for security.
`r Flexibility: Anembedded system is often required to execute multiple and di-
`verse security protocols and standards in order to support (i) multiple security
`objectives (e.g., secure communications, DRM, and so on), (ii) interoperability
`in different environments (e.g., a handset that needs to work in both 3G cellu-
`lar and wireless LAN environments), and (iii) security processing in different
`layers of the network protocol stack (e.g., a wireless LAN enabled PDA that
`needs to connect to a virtual private network, and support secure web brows-
`ing may need to execute WEP, IPSec, and SSL). Furthermore, with security
`protocols being constantly targeted by hackers, it is not surprising that they
`keep continuously evolving (see also Section 5.4). It is, therefore, desirable
`to allow the security architecture to be flexible (programmable) enough to
`adapt easily to changing requirements. However, flexibility may also make
`it more difficult to gain assurance of a design’s security.
`r Tamper Resistance: Attacks due to malicious software such as viruses and
`trojan horses are the most common threats to any embedded system that is
`capable of executing downloaded applications [Howard and LeBlanc 2002;
`Hoglund and McGraw 2004; Ravi et al. 2004]. These attacks can exploit vul-
`nerabilities in the operating system (OS) or application software, procure ac-
`cess to system internals, and disrupt its normal functioning. Because these
`attacks manipulate sensitive data or processes (integrity attacks), disclose
`confidential information (privacy attacks), and/or deny access to system re-
`sources (availability attacks), it is necessary to develop and deploy various
`HW/SW countermeasures against these attacks.
`In many embedded systems such as smartcards, new and sophisticated at-
`tack techniques, such as bus probing, timing analysis, fault induction, power
`analysis, electromagnetic analysis, and so on, have been demonstrated to
`be successful in easily breaking their security [Ravi et al. 2004; Anderson
`and Kuhn 1996, 1997; Kommerling and Kuhn 1999; Rankl and Effing; Hess
`et al. 2000; Quisquater and Samyde 2002; Kelsey et al. 1998]. Tamper resis-
`tance measures must, therefore, secure the system implementation when it
`is subject to various physical and side-channel attacks.
`Later in this paper (see Section 6), we will discuss some examples of em-
`bedded system attacks and related countermeasures.
`r Assurance Gap: It iswell known that truly reliable systems are much more
`difficult to build than those that merely work most of the time. Reliable
`
`ACM Transactions on Embedded Computing Systems, Vol. 3, No. 3, August 2004.
`
`MOBILEIRON, INC. - EXHIBIT 1010
`Page 007
`
`

`

`468
`
`•
`
`S. Ravi et al.
`
`systems must be able to handle the wide range of situations that may oc-
`cur by chance. Secure systems face an even greater challenge: they must
`continue to operate reliably despite attacks from intelligent adversaries who
`intentionally seek out undesirable failure modes. As systems become more
`complicated, there are inevitably more possible failure modes that need to
`be addressed. Increases in embedded system complexity are making it more
`and more difficult for embedded system designers to be confident that they
`have not overlooked a serious weakness.
`r Cost: One of the fundamental factors that influence the security architecture
`of an embedded system is cost. To understand the implications of a security-
`related design choice on the overall system cost, consider the decision of
`incorporating physical security mechanisms in a single-chip cryptographic
`module. The Federal Information Processing Standard (FIPS 140-2) [FIPS]
`specifies four increasing levels of physical (as well as other) security require-
`ments that can be satisfied by a secure system. Security Level 1 requires
`minimum physical protection, Level 2 requires the addition of tamper-evident
`mechanisms such as a seal or enclosure, while Level 3 specifies stronger de-
`tection and response mechanisms. Finally, Level 4 mandates environmental
`failure protection and testing (EFP and EFT), as well as highly rigorous de-
`sign processes. Thus, we can choose to provide increasing levels of security
`using increasingly advanced measures, albeit at higher system costs, design
`effort, and design time. It is the designer’s responsibility to balance the secu-
`rity requirements of an embedded system against the cost of implementing
`the corresponding security measures.
`
`5. SECURITY PROCESSING REQUIREMENTS AND ARCHITECTURES
`Security processing refers to the computations that must be performed in a
`system for the purpose of security. In this section, we will analyze the chal-
`lenges imposed by security processing on embedded system design in greater
`detail, using the popular Secure Sockets Layer (SSL) protocol as an example.
`Section 5.1 examines the working of the SSL protocol. Section 5.2 analyzes the
`workload imposed by SSL on a typical embedded processor. Section 5.3 further
`examines how various embedded processors fare against the workload imposed
`by security processing and provides a quantitative analysis of the processing
`gap in both low- and high-end embedded systems. Section 5.4 explores the
`flexibility concerns arising from the evolutionary nature of security protocols,
`while Section 5.5 presents the impact of security processing on battery life in
`battery-powered embedded systems. Finally, Section 5.6 presents a taxonomy
`of security processing architectures that can address various aspects of the
`outlined problems.
`
`5.1 Anatomy of a Security Protocol
`The cryptographic primitives described in Section 3 are used to provide the
`basic services offered by most security protocols: encryption, peer authentica-
`tion, and integrity protection for data exchanged over the underlying unpro-
`tected networks. In this section, we will examine the functioning of a popular
`
`ACM Transactions on Embedded Computing Systems, Vol. 3, No. 3, August 2004.
`
`MOBILEIRON, INC. - EXHIBIT 1010
`Page 008
`
`

`

`Authentication,
`Key exchange
`r-······ .....................
`
`·,
`
`..
`
`Privacy, Integrity
`
`Security in Embedded Systems
`
`•
`
`469
`
`Application data
`
`Compression
`
`MAC trailer
`
`Message Integrity
`
`____... Padding
`
`Padding
`
`i---r-dl"I! Encrypted
`1 - - -~~=-~, data
`\
`\
`
`'
`
`Encryption
`
`~
`
`SSL record
`
`eader SSL Record Assembly
`
`Fig. 4. The SSL protocol, with an expanded view of the SSL record protocol.
`
`security protocol SSL [SSL], which is widely used for secure connection-oriented
`transactions.
`The SSL protocol is typically layered on top of the transport layer of the net-
`work protocol stack, and is either embedded in the protocol suite or is integrated
`with applications such as web browsers. The SSL protocol itself consists of two
`main layers as shown in Figure 4. The SSL record protocol, which forms the
`first layer, provides the basic services of confidentiality and integrity. The second
`layer includes the SSL handshake, SSL change cipher, and SSL alert protocols.
`Let us now examine how the SSL record protocol is used to process application
`data. The first step involves breaking the application data into smaller frag-
`ments. Each fragment is then optionally compressed. The next step involves
`computing a message authentication code (MAC), which facilitates message
`integrity. The compressed message plus MAC is then encrypted using a sym-
`metric cipher. If the symmetric cipher is a block cipher, then a few padding bytes
`may be added. Finally, an SSL header is attached to complete the assembly of
`the SSL record. The header contains various fields including the higher-layer
`protocol used to process the attached fragment.
`Of the three higher-layer protocols, SSL handshake is the most complex and
`consists of a sequence of steps that allows a server and client to authenticate
`each other and negotiate the various cipher parameters needed to secure a
`session. For example, the SSL handshake protocol is responsible for negotiating
`a common suite of cryptographic algorithms (cipher-suite), which can then be
`used for session key exchange, authentication, bulk encryption, and hashing.
`The cipher-suite RSA-3DES-SHA1, for example, indicates that RSA can be used
`for key agreement (and authentication), while 3DES and SHA1 can be used for
`bulk encryption and integrity computations, respectively. More than 30 such
`cipher suite choices exist in the OpenSSL implementation [OpenSSL] of the
`SSL protocol, resulting from various combinations of cipher alternatives for
`implementing the individual security services.
`Finally, the SSL change cipher protocol allows for dynamic updates of cipher
`suites used in a connection, while the SSL alert protocol can be used to send
`
`ACM Transactions on Embedded Computing Systems, Vol. 3, No. 3, August 2004.
`
`MOBILEIRON, INC. - EXHIBIT 1010
`Page 009
`
`

`

`470
`
`•
`
`S. Ravi et al.
`
`-
`
`Asymmetric llsymmetric 0Hash ~Protocol
`
`SSL
`stages
`
`Client
`operations
`
`Fig. 5. Typical sequence of client-side operations performed during an SSL session.
`
`alert messages to a peer. Further details of the SSL protocol can be found in
`SSL and Stallings [1998].
`
`5.2 Security Processing Workloads
`We will now examine the workload imposed by security processing by consid-
`ering the SSL protocol as an example.
`Figure 5 shows the typical (client-side) sequence of operations for a secure
`session that uses the SSL protocol. The first stage involves loading the client
`certificate from local storage, decrypting it using a symmetric cipher, and per-
`forming an integrity check. Once the SSL handshake is initiated, the client
`and server exchange a sequence of messages that result in the client-side oper-
`ations as shown in the figure. The objectives of these operations include (i) server
`authentication, where the client verifies the digital signature of the trusted cer-
`tificate authority (CA) on the server certificate using the public key of the CA,
`followed by an integrity check, (ii) client authentication, where the client op-
`tionally generates a digital signature by hashing some data using the MD5 or
`SHA-1 algorithms, concatenating the digest, and signing the result with its pri-
`vate key, and (iii) key exchange, where the client generates a 48-byte premaster
`secret (used to generate the secret key for the SSL record protocol) and encrypts
`it with the public key of the server. The specific manner in which these objectives
`are met depends on the cipher suite being used, but the ultimate result of a suc-
`cessful handshake is that the client and server have completed any necessary
`authentication steps and share a secret key. Once the connection is established,
`secure transmission of data proceeds through the SSL record protocol.
`Figure 6 shows a function call graph obtained for an SSL session us-
`ing the OpenSSL implementation [OpenSSL]. The profile has several hun-
`dred functions which can be classified from a functional perspective into
`four categories: asymmetric computations (e.g., function RSA public decrypt,
`which implements the RSA algorithm), symmetric computations (e.g., func-
`tion des encrypt2, which implements the basic DES cipher), hashing opera-
`tions (functions such as SHA1 Update and MD5 Update, which implement the
`SHA-1 and MD5 algorithms), and protocol processing computations (e.g., func-
`tions such as initialize ctx that initializes the session context, block host order
`and block data order that reorder bytes for endianness, record assembly, and
`so on).
`
`ACM Transactions on Embedded Computing Systems, Vol. 3, No. 3, August 2004.
`
`MOBILEIRON, INC. - EXHIBIT 1010
`Page 010
`
`

`

`J_j.
`F11 e
`
`V1ew Windows
`
`Security in Embedded Systems
`
`•
`
`471
`
`_J_
`Help
`
`- - - \-.. ,_,..,_.,.~
`
`main
`~
`
`rem
`
`des_ed3_cbc_encrypt
`
`BN_mod_exp_mont
`
`rrul_montgomery
`
`SSL function
`call graph
`
`Fig. 6. Function call graph for the OpenSSL implementation of the SSL protocol (client-side).
`
`A quantitative breakup of the processing workload imposed by the above
`components is given in Figure 7, for three different transaction sizes (1 KB,
`100 KB, 1 MB). The measurements were performed on an iPAQ H3670 PDA,
`which contains an Intel SA-1110 StrongARM processor clocked at 206 MHz.
`From the figure, we can see that the protocol processing workload, which refers
`to the workload due to noncryptographic computations, increases with transac-
`tion size. The cryptographic processing workload is dominated by asymmetric
`ciphers for small transactions, and by symmetric ciphers for large transactions.
`
`5.3 Security Processing Gap
`We will now analyze how the workload imposed by security processing, in rela-
`tion to the processing capabilities of embedded processors, leads to a “security
`processing gap.” In order to quantify the security processing gap, we considered
`the client-side workload imposed by a single secure session between a client and
`server using the SSL protocol on various embedded processors. For our exper-
`iments, we considered the following platforms: (i) PDAs featuring StrongARM
`(206 MHz SA-1110) and XScale (400 MHz) processors, (ii) a workstation hav-
`ing a 768 MHz Pentium III Coppermine processor, and (iii) a server having a
`2.8 GHz Xeon processor. The OpenSSL implementation [Open SSL] of the SSL
`protocol was used wit