Securing Telemetry Post Processing Applications with Hardware Based Security
Total Page:16
File Type:pdf, Size:1020Kb
Securing Telemetry Post Processing Applications with Hardware Based Security Item Type text; Proceedings Authors Kalibjian, Jeff Publisher International Foundation for Telemetering Journal International Telemetering Conference Proceedings Rights Copyright © International Foundation for Telemetering Download date 29/09/2021 00:04:49 Link to Item http://hdl.handle.net/10150/605052 Securing Telemetry Post Processing Applications with Hardware Based Security Jeff Kalibjian Hewlett Packard Corporation ABSTRACT The use of hardware security for telemetry in satellites utilized for intelligence and defense applications is well known. Less common is the use of hardware security in ground-based computers hosting applications that post process telemetry data. Analysis reveals vulnerabilities in software only security solutions that can result in the compromise of telemetry data housed on ground-based computer systems. Such systems maybe made less susceptible to compromise with the use of hardware based security. KEY WORDS Hardware Security Modules (HSM), Hardware Security Module Hybrids (HSMH), Federal Processing Information Standard 140-2 (FIPS 140-2), Common Criteria (CC), security boundary, key management. INTRODUCTION Today most security features on computer systems are implemented as software only solutions. Examples of such security functions include authentication, privacy, and security protocol utilization (e.g. SSL). After reviewing pertinent security standards and discussing the fundamental threats in software-based security implementations; important hardware based security principles will be reviewed that are most applicable to support telemetry post processing. An example will be given illustrating how FIPS 140-2 Level 4 Hardware Security Modules (HSM) and Hardware Security Module Hybrids (HSMH) maybe utilized to better secure the telemetry post-processing activity by allowing policy evaluation, key management and data manipulation activities to be done inside a hardware security boundary. SECURITY STANDARDS The two most important security standards in the industry are FIPS 140-2 and Common Criteria. The National Institute of Standards and Technology (NIST) has established a Federal Information Processing Standard (FIPS) that specifies the security requirements within a system protecting sensitive information pertaining to cryptographic operations [1]. The standard defines four increasing levels of security: • Level 1 defines the lowest level—no specific physical security mechanisms are required however one “approved” NIST cryptographic algorithm (e.g. DES) or security function must be utilized. The software and/or firmware components of the cryptographic module maybe executed on a general purpose processor that has an un-rated operating system. • Level 2 adds a requirement of physical tamper evidence (e.g. tamper evident coatings or seals on containers housing the electronics). It also specifies role-based authentication for security officer interaction with the cryptographic module (e.g. for key loading, etc.). If software and/or firmware components implement the cryptographic capabilities, they maybe executed on a general purpose processor, but the OS on the processor must be rated at CC EAL-2 or its equivalent. •Level 3 requirements include all Level 2 requirements, but add constraints to minimize threat of data compromise. This usually takes the form of data zeroization circuitry. It also requires identity-based authentication for security officers needing to access the processor system. Any software/firmware cryptographic functionality provided by a general purpose processor, requires an OS on that processor rated at CC EAL-3. •Level 4 is the highest standard and requires physical security that detects and responds to all unauthorized attempts at access. In addition to Level 3 features, Level 4 provides for zeroization even when environmental conditions such as temperature, voltage, are exceeded. Level 4 also requires an operating system rated at CC EAL-4 or higher if software or firmware is utilized to implement cryptographic functionality. Table 1 summarizes the FIPS 140-2 four assurance levels: FIPS 140-2 Rating Comments Level 1 Not meaningful Level 2 Not meaningful Level 3 Secure Level 4 Very Secure Table 1: Implications of the FIPS 140-2 ratings. The security worthiness of software is usually evaluated with the Common Criteria metric [2]. In Common Criteria evaluation a set of security requirements and specifications, otherwise known as a Protection Profiles (PP) and Security Targets (ST), are developed for a software system referred to as the Target of Evaluation (TOE). Common Criteria is an ISO standard (15408) and has seven Evaluation Assurance Levels (EALs): • EAL - 1: Functionally tested. Evaluation of TOE is done with respect to the customer documentation. Used when threats to security are not considered serious and only some confidence of correct operation is desired. • EAL - 2: Structurally tested. Evaluation of TOE is done with respect to developer design information and test results. Used when developers or users require a low to moderate level of independently assured security. • EAL – 3: Methodically tested and checked. Evaluation of TOE is done at design stage. Used when developers or users require a moderate level of independently assured security. • EAL – 4: Methodically designed, tested, and reviewed. Used when developers or users require a moderate to high level of independently assured security. • EAL – 5: Semi--formally designed and tested. Rigorous commercial development tools and specialty security design techniques to design and implement TOE. Used when developers or users require a high level of independently assured security. • EAL – 6: Semi-formally verified design and tested. Security engineering techniques applied to an advanced development environment. Used when developers or users are developing applications deployed in high risk situations pro- tecting valuable assets. • EAL – 7: Formally verified design and tested. Advanced security engineering and development techniques that can be rigorously mathematically modeled and analyzed. Used for applications deployed in extremely high risk environments protecting large value assets. Table 2 summarizes the seven CC evaluation service levels: CC EAL Rating Comments EAL-1 Not meaningful EAL-2 Not meaningful EAL-3 Not meaningful EAL-4 Some Security EAL-5 Pretty Secure EAL-6 Secure EAL-7 Very Secure Table 2: Implications of Common Criteria EAL ratings. A process of PP and ST definition feed into the development, evaluation, and operation of the TOE. This represents a continual process of feedback and evaluation that eventually leads to the implementation and evaluation of the secure software system utilizing varying levels of sophistication in software security design and development. While ideally this occurs starting at the requirements phase, it is economically feasible to retrofit existing designs with Common Criteria methodology and achieve up to EAL-4 ratings. COMPUTER SECURITY The threat model for all computer systems has four elements: • External threats introduced into the computer system. Examples of this would be viruses or malicious scripts. • Internal threats: misplaced trust. This includes overloading privileges onto the Adminis- trator role and allowing the Administrator to exercise their privileges without dual control. • Attacks against the operating system or applications running on the operating system. This can include replacing known operating system resources with compromised ones, or attacking the memory partition an application is running in. • Internal and external data snooping. This might involve access to sensitive data residing in CPU registers or main memory via fault dumps or Logic State Analyzer (LSA) access to system bus activity. Securing a computing system involves introducing cryptographic technology, preferably in secure hardware boundaries, that provides privacy, authentication, and authorization services. It is assumed the reader has familiarity with how cryptography is utilized to deliver such capabilities. The reader is encouraged to consult [3] for a rigorous discussion of cryptography. A primary concern in cryptography is protecting the keying material that helps to deliver services like privacy and authentication. An example illustrates the difficulty in protecting such key material using software only techniques: Consider a telemetry data product that has been reduced. That is, certain post processing activities have been performed on the data, and because of the data sensitivity, it has also been encrypted for privacy concerns. A fundamental question arises: how is the key (Kt) that encrypted the reduced data products being protected? In the most common scenario, the key itself has been encrypted using a methodology known as password based encryption. That is, a user generated password is hashed and the result is utilized as a cryptographic key (Kp) that in turn is used in a cryptographic algorithm to encrypt the key (Kt). The encrypted key (EKt) is then typically stored on disk for later access. When the encrypted telemetry data needs to be accessed, the following steps need to take place. First the password utilized to derive the key (Kp) that encrypted Kt must be col- lected and temporarily stored in computer memory. After the password is hashed to derive Kp, the password maybe deleted, but then Kp must be stored temporarily in computer memory while it is being used to decrypt Kt.. Once