Secure Delivery - Common Criteria approach and ...

15th International Common Criteria Conference

Secure Delivery - Common Criteria approach and Real Threats Jens O. Oberender* SRC Security Research & Consulting GmbH, Graurheindorfer Str. 149a, 53117 Bonn, Germany

ABSTRACT Secure delivery is the process of transferring certified products to the user. Manipulation during this phase might be undetectable, e.g. implanting Advanced Persistent Threats. Even security domains that Common Criteria approaches rely on may be exploited. The paper assesses the security claims for secure delivery and deferrals to post-delivery phase. Results of assurance components may be subverted if not protected during delivery. Risk management and Common Criteria differ in the responsibility of risk decision making, but a certification may leave residual risks beyond technology. The paper outlines approaches that focus on how users can validate they are using an authentic TOE.

1. Motivation Secure delivery is one of the aspects necessary to bring a product into secure operations. While the Common Criteria puts major efforts into the development of high assurance levels, comparatively little attention has so far been devoted to the attack resistance of delivery procedures. However, recent leaks have revealed delivery attacks that undermine product security at a large scale. Leaked documents show that commercial hardware was regularly intercepted during delivery. The interception goal was the integration of software / hardware implants during product delivery. The implants are suspected to infiltrate Internet infrastructure and services.

1.1. Structure This paper addresses secure delivery assessment. The certification of IT security products continuously obtains new ways to overcome measures. First the paper summarizes the impact of implants and sketches its applicability during delivery. Next, a Common Criteria approach that relies on security domains is presented and Advanced Persistent Threats for hardware and software are introduced. The existence of these motivates the need for secure delivery. Part II describes the five claims for secure delivery, and the efforts that are necessary to defer authenticity checks into responsibility of the user. Section 2.3 summarizes ways how unauthentic delivery may violate the TSF and commensurable measures are discussed. Part II ends with the proposal of self-defence that shall allow a user to judge about TOE infiltration. Part III concludes the paper.

1.2. Delivery Interception Rants In recent years the IT security community has been facing professionalized aggression against IT security products. The Stuxnet Trojan that was discovered in 2010 involved four zero day exploits, undermining security controls in industry factories with the goal to subvert industry control software. Estimations say it took six month and 5-10 developers to implement this attack. The effort invested into the Stuxnet attack was unprecedented and the complexity of the exploitation path set a new landmark. Hardware. In his book ‘No Place to Hide’ Glenn Greenwald reports that intelligence services regularly intercept IT security products during

delivery. According to his sources from 2010, an NSA department called ‘Tailored Access Operations’ placed implants into routers, servers, and other computer network devices (Greenwald, 2014). Also a wide offer of hardware extensions for the purpose of spy and manipulation has become available both on the commercial and intelligence market (Jacob Applebaum and Christian Stöcker, 2013). Some of these implants are integrated into products during order delivery. Software. Attacks during delivery impact the security during operation. Weaknesses in the authorization scheme OAuth stress the importance of software confidentiality after development. A weak implementation allows misuse of the cloud credentials within the software thus enabling illegitimate access of third parties (Ryan Paul, 2010). Powerful adversaries that scan the Internet traffic can identify software downloads. Once such a download was discovered, an adversary can acquire crash information, memory dumps, and error conditions which users may sent to enhance software quality. As a side channel information an adversary learns about the installed software, its current malfunctioning and thus exploitable vulnerabilities (Spiegel, 2013).

1.3. Security Domains and Open Configuration A Common Criteria evaluation covers all aspects that contribute to the secure operation of the TSF. If the security architecture of the TOE provides a strong separation of security domains, the evaluation scope may be limited to one domain. Malicious implants typically aim at the assets of the certified product, i.e. credentials such as private keys, and thus rely on a breach of separation. Software products with separated security domains may e.g. be found on the Java Card Platform, where applets run in separated domains. The Java Card Platform regulates the inter-process communication by filtering it according to the needs of each applet. The downside is that the Java Runtime Environment may still be exploited and by breaking the process isolation the platform is founded on (Charlie Lai, 2008). The open configuration of a Java Card platform allows the installation of additional applets after delivery. Any additional applet could potentially compromise the security domain of other applets. The Joint Interpretation Working Group created a proposal for open configuration evaluation (Joint Interpretation Working Group, 2013). While the platform and initial applet were subjected to evaluation, applets that are unknown at the time of evaluation may involve ill-typed opcodes that can breach the Runtime Engine (Wojciech Mostowski and Erik Poll, 2008).

Corresponding author: Tel +49-228-2806182; E-mail address: [email protected], © Jens Oberender, SRC Security Research & Consulting GmbH

2

SECURE DELIVERY - COMMON CRITERIA APPROACH AND REAL THREATS

The JIL approach bases on a strong platform firewall and requires the card owner to perform byte verification of new applets before installation. The benefit of the JIL approach is the secure integration of noncertified with certified software. Post-delivery tampering of software may breach security domains unless this is prevented by strong separation. This paper therefore investigates tamper prevention during delivery.

1.4. Advanced Persistent Threats Since some products defer security checks after delivery, the author raises the question of whether a check by skilled users is a proper measure against Advanced Persistent Threats. Checking might be helpful to detect accidental misconfigurations. However, stealth features render detection approaches in a black box manner unlikely. Advanced Persistent Threats (APT) are made up of vulnerabilities and hidden product functionalities which cannot be corrected without impact to critical IT processes. Sources of APT can be non-conformance to development processes, shallow depth of testing, and insecure delivery.

2.1. Secure Delivery Claims According to ALC_DEL application notes, delivery shall avoid or detect interception, tampering and delays during delivery. The procedure must ensure that the TOE user receives the certified version of the TOE. Depending on the TOE nature, knowledge of TOE delivery shall also be hidden from third parties. Summarizing, the vendor must consider the following four properties in its secure delivery procedure: • •

•

• Hardware • PCI implants can infect computer software during reboot, thus ensuring malware presence after clean media recovery of the operating system. The detection of such an implant may become difficult if the presence of malware is non-deterministic, e.g. once per month while booting. • Hard disk firmware implants delude the search strategy of antivirus products. During boot phase a malicious master boot record (including malware) is delivered to the CPU. A healthy Master Boot Record is presented to scanning products that query the same disk sector at later stages. • Bugging devices exploit the TOE environment as they are used to monitor information exchange at the TOE boundary. Key logging devices, for example, can be bought commercially as hardware sockets Software • BIOS implants can infect targets with Flash based BIOS firmware at random times. • Bluepill is exploit software which hides its presence by means of virtualization techniques. The memory and disk sectors of bluebill are “100% hidden” from the guest operation system thus omitting detection by antivirus tools. • Port scanning is known to identify ports allocated by services. The sequence during port knocking is the ‘open sesame’ to an otherwise inactive service. Such backdoors can be detected during evaluation of development aspects if they fall within the scope of the TOE but not after delivery. Secure, authentic delivery is necessary to prevent APTs.

2. Secure Delivery Assessment The scope of assessing delivery is defined by the TOE scope resp. the Common Criteria certificate. Typically, it comprises the TOE software and hardware together with guidance documents for secure preparation and operation.

•

Authenticity provides confidence to the TOE user that he has received an untampered security product by the vendor. The Binding to the Security Certificate ensures that delivered product matches with the security evaluated TOE. I.e. the same vendor may have products with test interfaces that subvert TSF or a different implementation with the same functionality. Guaranteed delivery – if the receiver strongly relies on the services provided by the product, an adversary shall not be able to delay or cancel delivery. Confidentiality protects productive keys (if included in shipment). Documents that guide secure configuration may also include TOE knowledge that can be abused by an attacker. An attacker may also learn details about the TOE and abuse this knowledge later to exploit weaknesses of the delivered TOE version. Unobservability hides the correlation between a delivered product and its receiver. It originates from privacy research (Andreas Pfitzmann and Marit Hansen, 2010) and becomes relevant if an adversary is able to monitor the Internet connection between the vendor and user. The possession of some TOEs shall be hidden from third parties, e.g. an attacker knowing about the presence of an advanced IDS solution or honeypot can more efficiently anticipate his traces.

The delivery procedure presented to the evaluator must ensure ‘security of the TOE is maintained during distribution of the TOE to the user’ (Common Criteria Part 3 (2012), page 138f, para 365). Physical goods of large entities are delegated to parcel services, exposing the security chain for the duration of transport. The delivery risks that are taken by standard transport services, like physical destruction and loss, only partially fulfil the needs of a secure delivery.

2.2. Defer Security past Delivery Phase According to CC the delivery phase ends with transfer of responsibility to the user. The vendor may include obligations in the next life cycle phase to remedy threats that may occur during TOE delivery. This is viable if evaluation lab and certification body agree that avoiding interception may be substituted by tamper detection (Common Criteria Part 3 (2012), page 369, bullet b). This construct might be accepted by certifiers as the product effectiveness often relies on the user expertise during configuration and operation. Software. Validating secure delivery of digital goods during preparation may rely on cryptographic primitives and widely deployed solutions, i.e. hashing and digital signature schemes. Establishing trust into certificate chains for mass delivery has become difficult (Carl Ellison and Bruce Schneier, 2000). The consistency of the Common Criteria certified TOE with the delivered product may depend on an authentic certificate including a cryptographically secure hash. Please note that such measures only ensure that the certificate binding is maintained, e.g. the

3

SECURE DELIVERY - COMMON CRITERIA APPROACH AND REAL THREATS

present product is identic to the tested one. Depending on the evaluation assurance level, the TOE might not have been free from vulnerabilities. Hardware. Verifying properties of physical goods after secure delivery - namely hardware, digital media and printed documentation - is more challenging. Customized, sealed, and security taped packaging may provide authenticity against low attack potential but certainly disregards unobservability. The supply chain community discusses the range of security relevant efforts during production (European Network and Information Security Agency, 2012). As attackers aim at the weakest link, the verification efforts must balance controls during production such as receiving inspections with the controls being postulated for post-delivery measures. A TOE user may not have the necessary knowledge to perform meaningful examinations of visible manipulations. Measures such as digital attestation require a physical trust base that increase the per-item costs and are therefore only found in high profile security products. The preparation procedure must be designed in a way that ensures the intended TOE user is able to confirm conformance. Physical tampering attacks (APT, see section 1.4) will be undetectable from users with normal expertise. In this case the security rationale must ensure secure delivery during distribution.

2.3. Security Control Bypass

Being hit by a comet is a risk which cannot be easily countered. Thus, IT risk management assesses likelihood - how often does the incident occur - and its impact – do assets suffer from the incident. In the context of product certification, impact can refer to a single TOE instance, e.g. asset leakage, or all TOEs are vulnerable, e.g. a systematic breach in the security architecture. IT compliance and risk management strives to understand all existing risks, but countermeasure must be adequate to the risk appetite of the organization. The residual risks are documented and need regular inspection on exploitability. Table 1 –Bypass Examples Control Derogation

Relevant Family

Responsibility Involvement

Development (ALC_DVS)

Developer

Production (ALC_DVS)

Manufacturer

Delivery (ALC_DEL)

Developer

- Fail of external security anchor

Preparation (AGD_PRE)

User

- Undermine TOE environment conditions

Operational (AGD_OPE)

User

Retirement (ALC_LCD)

Developer

- Include vulnerable code into build - Maliciously alter configuration items - Replace secure parts of the design - Hardware implants for leakage and malfunction - Manipulate guidance documents - Persistent implants

Recent IT incidents showed that the established controls are not effective and thus a single control layer cannot be considered sufficient. Strong security models involve multiple layers of security control, e.g. ISO/IEC 27001 (ISO/IEC, 2013). The Common Criteria covers controls during the early life cycle phases and establishes guidance for the later stages. Table 1 shows derogation of the TSF in the phases of the product life cycle. Many of them can occur during delivery phase, e.g. vulnerable code or hardware may be implanted before the TOE reaches the responsibility of the user. Initially the vendor assumes complete responsibility of the TSF implementation. As part of the product rollout the trust into certain aspects relies on third parties such as the hardware manufacturer and the user being in charge of preparation and operation.

2.4. Commensurable Measures for Delivery Originally, the evaluator concludes - after reviewing developer documents - about the Evaluation Assurance Level that is actually reached by the presented measures. A side effect of the assessment is that the evaluator has examined the strength of different CC classes and that a consultant supports the developer in eliminating weaknesses. The result is a TOE and lifecycle that show the same resistance against attacker potential in the TOE design, its lifecycle, and guidance to the user. Secure delivery must be adequate to the measures that protect the quality of TSF implementation (ADV_IMP), the security architecture (ADV_ARC), the depth of testing (ATE), the controls regarding the development and production areas (ALC_DVS), the trust into supply chain (ALC_LCD) and the user expertise for compliance with procedures in preparative and operational guidance. Ideally, the efforts for these aspects have a similar strength (Common Criteria Management Board, 2012, part 3, page 138, ALC_DEL, para 366). Beside the TOE type commensurable delivery procedures must relate to the assumed attack potential and the assurance strength chosen by the Evaluation Assurance Level. Table 2 exemplifies the demands that follow from other CC classes for secure delivery.

- Misconfiguration - Prevent that massive TOE instances are used for vulnerability assessment

Table 2 –Demands for Secure Delivery Assurance Issues and Consequences for Depth of Secure Components Delivery Assessment ALC_DEL

- Secure delivery is not assessed

ALC_LCD

- Are all TOE software / hardware contributions authentic? Ensure that product including TOE is delivered authentic

ALC_FLR

- How are vulnerability reports concealed from third parties during submission? Unobservable delivery

AGD_PRE

- Has the normal TOE user the expertise to detect violated TOE authenticity? Protect TOE authenticity during delivery

AGD

- Is misconfiguration by skilled TOE users prevented? Ensure that authentic guidance documents are delivered

ADV_ARC

- Assessing secure initialization and security domain. Prevent implants during delivery

ADV_IMP

- Implementation flaws and backdoors are detectable. Mitigate APTs during delivery

ATE_DPT

- Ensure subsystem interfaces to comply with TOE design; Prevent implants during delivery

AVA_VAN

- Mitigation of enhanced-basic/moderate/high attack potential (including delivery)

Common Criteria transfers risk acceptance to the certification body. The acceptance criteria solely relate to the exploitability based on the Evaluation Assurance Level. This has immense consequences, as the risk

4

SECURE DELIVERY - COMMON CRITERIA APPROACH AND REAL THREATS

appetite of the developing organization may accept a residual risk, but the certification body enforces coverage of the full attack potential. This conflict is then escalated to the organizations need for a certain EAL certification. However, some residual risks remain residual in high assurance levels such as bribe, blackmailing, and armed assault. Developer cooperation forms a trust base during the evaluation, although national security letters exist. The risk appetite also strongly prejudices the choice of the TOE scope resp. shifting responsibilities into the TOE environment. For example, boot loaders and firmware update functionality may be excluded from the TOE scope, although they constitute the only mitigation against APTs. Both International Technical Communities and certification bodies must enforce transparent description in the TOE Summary Specification. This will allow customers to judge APT resistance during product procurement.

The paper defines properties for secure delivery. Often secure delivery is deferred to the product recipient, e.g. for checking authenticity. There are a number of known Advanced Persistent Threats that are undetectable after the integration of an implant. Common Criteria requires commensurable protection measures for delivery. However, residual risks may exist even though they do not exceed the attacker potential. The paper derives dependencies to delivery that originates from assurance components. For high evaluation assurance levels, delivery must be resistant to a number of different attack types, ranging from false guidance, manipulated firmware to APT implants in hardware. The required measures depend on the TOE type and the impact of infiltration of assets during delivery. Products designed for self-defence, would allow their users to detect the presence of today known APT and malware. Ensuring secure delivery is a replacement if the security state of a product cannot be examined during operation.

2.5. Self Defence

REFERENCES

The author believes that the secure delivery class and CEM are sufficiently described. However, reaching certified operations is challenged in the presence of strong attackers. Moderate attack potential constantly grows due to the knowledge of attackers, e.g. scientific publications. An example is the first hacking of payment terminals, where manipulated devices could be identified through the weight of the additional physical parts of the implants. The next attack wave eliminated this discrimination, raising the expertise level for successful detection. The secure delivery properties of section 2.1 apply to TOEs that are subject to a comprehensive assessment. Table 2 lists the consequences based on higher assurance components. Strong capabilities for authenticity checking after delivery should become a requirement for product design. Software. The user must be able to load authentic software without trust into delivery parts. For example firmware could be securely brought into by EEPROM burning. The number of trusted elements is such minimized: the loading tools and checksum are external to the TOE plus receiving of an authentic certificate. Hardware. Are implants detectable during production, assembly or after delivery and what expertise does the user need? Many products require advanced tools like x-ray to become aware of irregularities. Therefore authenticity must be ensured by appropriate delivery procedures, starting from sealed boxes up to tamper measures. Product design could also include JTAG interfaces that allow the user to assess the internal hardware state and understand whether the TOE is still in the invariant that has been assessed as secure state during evaluation. For mass products, security experts suggested anonymous purchase in order to prevent customized ATPs to be delivered (Cory Doctorow, 2013); (Tim Cross, 2014); (Bruce Schneier, 2013). This is in response to the suspected targeted infiltration. Adversaries are thought to abuse eCommerce processes and unsecure supply chains to purposefully customize IT products in malicious intent.

Andreas Pfitzmann and Marit Hansen (2010). A terminology for talking about privacy by data minimization: Anonymity, Unlinkability, Undetectability, Unobservability, Pseudonymity, and Identity Mangement. Version 0.34, http://dud.inf.tu-dresden.de/Anon_Terminology.shtml Bruce Schneier (2013). Want to Evade NSA spying? Don’t connect to the Internet. Wired Opinion, http://www.wired.com/2013/10/149481/ Carl Ellison and Bruce Schneier (2000). Ten Risks of PKL: What You’re not Being Told about Public Key Infrastructure. Computer security Jorunal, Volume XVI, Number 1, https://www.schneier.com/paper-pki.html Cory Doctorow (2013). TAO: the NSA’s hacker plumber-wunderkinds, http://boingboing.net/2013/12/29/tao-the-nsas-hacker-plumber.html Charlie Lai (2008). Java Insecurity: Accounting for Subtleties That Can Compromise Code, IEEE Software, 1/2008. ISSN 0740-7459/08 Common Criteria Management Board (2012). Common Criteria for Information Technology Security Evaluation, Part 3: Security Assurance Components, Version 3.1. Revision 4 Final, https://www.commoncriteriaportal.org European Network and Information Security Agency (2012). Supply Chain Integrity – An overview of the ICT supply chain risks and challenges, and vision for the way forward, http://www.enisa.europa.eu Glen Greenwald (2014). No Place to Hide. Metropolitan Books. 978-1627790734 International Organization for Standardization and International Electrotechnical Commission (2013). Information technology— Security techniques — Information security management systems — Requirements, ISO/IEC 27001:2013. Jacob Applebaum and Christian Stöcker (2013). Shopping for Spy Gear: Catalog Advertises NSA Toolbox. Der Spiegel, http://www.spiegel.de/international/world/catalog-reveals-nsa-has-back-doorsfor-numerous-devices-a-940994.html Joint Interpretation Working Group (2013). Certification of open smart card products. Version 1.1 (trial use), http://www.sogisportal.eu Ryan Paul (2010). Compromising Twitter’s Oauth security system, http://arstechnica.com/security/2010/09/twitter-a-case-study-on-how-to-dooauth-wrong/ Spiegel Online (2013). Inside TAO: Documents Reveal Top NSA Hacking Unit, http://www.spiegel.de/international/world/the-nsa-uses-powerful-toolbox-ineffort-to-spy-on-global-networks-a-940969.html Nikos Virvilis, Dimitris Gritzalis, and Theodoros Apostolopoulos (2013). Trusted Computing vs. Advanced Persistent Threats: Can a defender win this game? IEEE Autonomous and Trusted Computing. Wojciech Mostowski and Erik Poll (2008). Malicious Code on Java Card Smartcards: Attacks and Countermeasures. Smart Card Research and Advanced Applications, LNCS 5189. Tim Cross (2014). Who can you trust? Trust and the NSA. The Economist http://www.economist.com/node/21592603

3. Conclusions Procedures for secure delivery protect authentic and guaranteed delivery, possibly unobservable and confidential against adversaries. TOE users must have means to prove whether they have received the evaluated TOE. Recent attacks have abused weak delivery for malicious implants into IT security products.