4040-840 Security and Trust

all-inOne, section 10.

10. Trusted Computing Base/Platform

Literature: A Practical Guide to Trusted Computing (Paperback) by David Challener, Kent Yoder, Ryan Catherman, David Safford, Leendert Van Doorn

Paperback    384 pages
Publisher    IBM Press; 1 edition (January 6, 2008)
Language     English
ISBN-10      0132398427
ISBN-13      978-0132398428

10.1. Definition

Trusted computing base (TCB) of a computer system is the set of

--: all hardware,
--: firmware, and/or
--: software components that are critical to its security

in the sense that bugs occurring inside the TCB might jeopardize the security properties of the entire system.

10.2. Computers in Airplanes

http://www.airliners.net/photo/0957790/

Flight By wire
Automatic Stability Systems
Flight by optics
AIRBUS A320/A330/A340 Electrical Flight Controls A Family of Fault-Tolerant Systems: http://personales.upv.es/juaruiga/teaching/TFC/Material/Trabajos/AIRBUS.PDF
INTEGRITYB.-178B RTOS: http://www.ghs.com/products/safety_critical/integrity-do-178b.html more on this later

10.3. Computers in the Medical Field

Pacemaker:may contain up to 80000 lines of code
Infusion pumps: may have more than 170000 lines of code
Medical Divices - http://www.coverity.com/library/pdf/governance-risk-and-compliance.pdf

10.4. Computers in Safety-Critical Applications

Cost versus required
Insurance
Areas

--: space
--: transportation
--: Nuclear
--: Military
--: ...

10.5. Space Shuttle

The brain of NASAb's primary vehicle has the computational power of an IBM 5150 http://www-03.ibm.com/ibm/history/exhibits/pc25/pc25_intro.html

--: Comaprison: 0.005 percent of an Xbox 360
--: 420,000 loc

10.6. Languages

Does the computer language matter?
What attribute of a language does matter?

Staticaly typed?

--: Goto's
--: Exhaustion of memory
--: Sepatate compilition with checks

--: http://www.dmoz.org/Computers/Programming/Languages/Ada/
--: developed with capbabilities that serve real-time and saftey-critical needs

Ip Hello World in Java.

with Ada.Text_IO; use Ada.Text_IO;
procedure Hello is
begin
  Put_Line("Hello my Friend!");
end Hello;

% gnatmake hello.adb

10.7. Fundamental Objectives

Policy - must be well defined and enforced by the computer system

Mandatory Security Policy
Discretionary Security Policy

Accountability - individual accountability regardless of policy must be enforced.

Identification
Authentication
Auditing

Assurance

Assurance Mechanisms - Operational Assurance - Life-cycle Assurance
Continuous Protection Assurance

Army Regulation

See chapter 2.3 1 - 9
chapter 2.7/9/14/19/22
chapter 3.3

10.8. Bruce Schneir on Security

http://www.schneier.com/blog/archives/2009/10/proving_a_compu.html

: Professor Gernot Heiser, the John Lions Chair in Computer Science in the School of Computer Science and Engineering and a senior principal researcher with NICTA, said for the first time a team had been able to prove with mathematical rigour that an operating-system kernelbthe code at the heart of any computer or microprocessorbwas 100 per cent bug-free and therefore immune to crashes and failures.

Don't expect this to be practical any time soon:

: Verifying the kernel - known as the seL4 microkernelbinvolved mathematically proving the correctness of about 7,500 lines of computer code in an project taking an average of six people more than five years. That's 250 lines of code verified per man-year. Both Linux and Windows have something like 50 million lines of code; verifying that would take 200,000 man-years, assuming no increased complexity resulting from the increased complexity. Clearly some efficiency improvements are required.

10.9. Formal Verification for Software

Validation:: Are we trying to make the right thing?", i.e., is the product specified to the user's actual needs?
Verification:: Have we made what we were trying to make?", i.e., does the product conform to the specifications?

See here: http://www.cs.indiana.edu/classes/p415/post/sorting_tutorial_2.pdf

10.10. Players

Software Developer
System administrators
ADMINISTRATION

10.11. Required

How can OS developer attempt to achieve this goal?

--: Micro Kernel
--: Verification

10.12. Micro-Kernel Architecture

Micro-Kernel Architecture (Mach, OSF, and NT)

[picture]

10.13. Levels

Model 1:

Untested
Tested
Verified

Model 2:

Software Fault Tolerance

10.14. Fault-Tolerant Software Design Approaches

From: http://ubiquity.acm.org/article.cfm?id=985602

Recovery Block Scheme (RBS):

one primary module for executing critical software functions
an acceptance test in order to test the primary module's output after each execution
one set of alternate modules performing the same function of the primary module.

N-Version Programming Scheme (NVPS)

N-independent programs execute in parallel on identical input, and results are obtained by voting upon

Community-Error-Recovery Scheme (CERS):

compare results at intermediate points of computation
offers higher fault tolerance than the basic NVPS and requires higher cost (synchronization)

Enhanced-Single-Version Scheme (ESVS):

single version of the application software
enriched with enhanced processing logic
using various thoughtful checkpoints in order to detect errors or faults in program and data flow immediately

10.15. The Gemini Digital Computer: First Machine in Orbit

During ascent, the computer received information about the velocity and course of the booster so that it would be ready to take over from the Titan's computers if they failed.
Switch-over could either be automatic or manual.

10.16. Case Study: Space Shuttle

From: http://history.nasa.gov/computers/Ch4-4.html

Cost
Fault tolerance on the Shuttle is achieved through a combination of redundancy and backup
rather than the expensive quality control employed in the Apollo program
Using the concept of fail operational/fail operational/fail-safe, five computers are needed. If one fails, normal operations are still maintained. Two failures result in a fail-safe situation, since the three remaining prevent the feared standoff possible in dual computer systems (one is wrong, but which?).
90% of avionics component failures were expected to be computer failures and that since a minimum of three computers and the backup should exist for a nominal re-entry,
Four of the computers, each loaded with identical software, operate in what is termed the "redundant set" during critical mission phases such as ascent and descent. The fifth, since it only contains software to accomplish a "no frills" ascent and descent, is a backup.
Management of redundancy raised several difficult questions. How are failures detected and certified?
Computer synchronization proved to be the most difficult task in producing the Shuttle's avionics. Synchronizing redundant computers and comparing their current states is the best way to decide if a failure has occurred
Computer synchronization proved to be the most difficult task in producing the Shuttle's avionics.
The essence of Shuttle redundancy is that each computer in the redundant set could do all the functions necessary at a particular mission phase. For true redundancy to take place, all computers must listen to all traffic on all buses
If there is a failure, then the failed computer could drop out of the set without any functional degradation whatever.
At the start, the Shuttle's designers thought it would be possible to run the redundant computers separately and then just compare answers periodically to make sure that the data and calculations matched69. As it turned out, small differences in the oscillators that acted as clocks within the computers caused the computers to get out of step fairly quickly.
the suggestion that the computers be synchronized at input and output points
Intercomputer communication is what makes the Shuttle's avionics system uniquely advanced over other forms of parallel computing. The software required for redundancy management uses just 3K of memory and around 5% or 6% of each central processor's resources, which is a good trade for the results obtained

10.17. Developing Software for the Space Shuttle

Landing
the orbiter begins a steep descent with the nose angled as much as 19 degrees down from horizontal. This glide slope is seven times steeper than the average commercial airliner landing. During the final approach, the vehicle drops toward the runway 20 times faster than a commercial airliner as its rate of descent and airspeed increase.
NASA awarded IBM Corporation the first independent Shuttle software contract on March 10, 1973p
The choice of a high level language for doing the majority of the coding was important
HAL/S

--: http://www.brouhaha.com/~eric/nasa/hal-s/hal-s-fc_users_manual.pdf
--: Programming in HAL/S
--: "HAL" was suggested as the name of the new language by Ed Copps, a founding director of Intermetrics, to honor Hal Laning, a colleague at MIT.
--: Compare to Java language specification (2005) http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#3.10.1
•: Compare to ANSI C language specification (1989) http://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html
--: Compare to C language specification (1978) http://en.wikipedia.org/wiki/The_C_Programming_Language (Prof. Dr. Axel T. Schreiner's Translation: http://www.amazon.de/Programmieren-C-Reference-Manual-deutscher-Sprache/dp/3446154973 )
--: IBM - (1/1/1) = HAL
--: HAL 9000
--: increased readability, through the use of a natural two-dimensional mathematical format;
--: increased reliability, by providing for selective recognition of common data and subroutines, and by incorporating specific data-protect features;
--: real-time control facility, by including a comprehensive set of real-time control commands and signal conditions.
•: See Figure 5-2

the success of the Shuttle's software development was due to the conceptual integrity established by using rigorously maintained requirements documents.
Shuttle requirements documents were arranged in three Levels: A, B, and C
The Primary Avionics Software System, or PASS, is the software that runs in all the Shuttle's four primary computers. PASS is divided into two parts: system software and applications software.NH 2 Trusted Computer System Evaluation Criteria
Unfortunately, the Shuttle software still has bugs, some of which are no fault of the flight software developers, but rather because all the tools used in the SPF are not yet mature. One example is the compiler for HAL/S. Just days before the STS-7 flight, in June, 1983, an IBM employee discovered that the latest release of the compiler had a bug in it.
There are two levels of code inspection, or "eyeballing" the software looking for logic errors. One level of inspection is by the coders themselves and their peer reviewers. The second level is done by the outside verification team. This activity resulted in over 50% of the discrepancy report

10.18. Claasification

(image from http://en.wikipedia.org/wiki/Trusted_Computer_System_Evaluation_Criteria)

Orange Book (We will look at the Criteria Part).
See also Rainbow Series: a series of security standards: Rainbow Series

Classification

D: Minimal Protection
C: Discretionary Protection
B: Mandatory Protection
A: Verified Protection

The rest is copied from: http://www.dynamoo.com/orange/summary.htm and the Orange Book

D: Minimal Protection

Any system that does not comply to any other category, or has failed to receive a higher classification. D-level certification is very rare.

C1 - Discretionary Security Protection

Discretionary Access Control, for example Access Control Lists (ACLs), User/Group/World protection.
Usually for users who are all on the same security level.
Username and Password protection and secure authorisations database (ADB).
Protected operating system and system operations mode.
Periodic integrity checking of Trusted Computer Base (TCB).
Tested security mechanisms with no obvious bypasses.
Documentation for User Security.
Documentation for Systems Administration Security.
Documentation for Security Testing.
TCB design documentation.
Typically for users on the same security level
C1 certification is rare. Example systems are earlier versions of Unix, IBM RACF.

C2 - Controlled Access Protection

As C1, plus

Object protection can be on a single-user basis, e.g. through an ACL or Trustee database.
Authorisation for access may only be assigned by authorised users.
Object reuse protection (i.e. to avoid reallocation of secure deleted objects).
Mandatory identification and authorisation procedures for users, e.g. Username/Password.
Full auditing of security events (i.e. date/time, event, user, success/failure, terminal ID)
Protected system mode of operation.
Added protection for authorisation and audit data.
Documentation as C1 plus information on examining audit information.
This is one of the most common certifications. Example Operating Systems are: VMS, IBM OS/400, Windows NT, Novell NetWare 4.11, Oracle 7, DG AOS/VS II.

B - Mandatory Protection

Division B specifies that the TCB protection systems should be mandatory, not discretionary.

B1 - Labelled Security Protection

As C2 plus: Mandatory security and access labeling of all objects, e.g. files, processes, devices etc.

Label integrity checking (e.g. maintenance of sensitivity labels when data is exported).
Auditing of labeled objects.
Mandatory access control for all operations.
Ability to specify security level printed on human-readable output (e.g. printers).
Ability to specify security level on any machine-readable output.
Enhanced auditing.
Enhanced protection of Operating System.
Improved documentation.
Example OSes are: HP-UX BLS, Cray Research Trusted Unicos 8.0, Digital SEVMS, Harris CS/SX, SGI Trusted IRIX.

B2 - Structured Protection

As B1 plus: Notification of security level changes affecting interactive users.

Hierarchical device labels.
Mandatory access over all objects and devices.
Trusted path communications between user and system.
Tracking down of covert storage channels.
Tighter system operations mode into multilevel independent units.
Covert channel analysis.
Improved security testing.
Formal models of TCB.
Version, update and patch analysis and auditing.
Example systems are: Honeywell Multics, Cryptek VSLAN, Trusted XENIX.

B3 - Security Domains

As B2 plus: ACLs additionally based on groups and identifiers.

Trusted path access and authentication.
Automatic security analysis.
TCB models more formal.
Auditing of security auditing events.
Trusted recovery after system down and relevant documentation.
Zero design flaws in TCB, and minimum implementation flaws.
The only B3-certified OS is Getronics/Wang Federal XTS-400.

A1 - Verified Protection

As B3 plus:

Formal methods and proof of integrity of TCB.
These are the only A1-certified systems: Boeing MLS LAN, Gemini Trusted Network Processor, Honeywell SCOMP.

A2 and above

Provision is made for security levels higher than A2, although these have not yet been formally defined. No OSes are rated above A1.

10.19. B3: Mandatory Protection: XTS-400

10.20. A1: Verified Protection: Scomp

Scomp: A Solution to the Multilevel Security Problem

10.21. XTS-400

Stolen from there.

General

XTS-400 adds support for contemporary hardware speeds and a robust set of LinuxB. Application Programming Interfaces
operating system that runs on the XTS is called the Secure Trusted Operating Program (STOP)
STOP 6.1.E received its evaluation at the EAL5 Augmented level in March 2005. (STOP)
STOP 6.1.E received its evaluation at the EAL5 Augmented level in March 2005. (STOP)
STOP 6.1.E received its evaluation at the EAL5 Augmented level in March 2005.
Note:

EAL4 is the highest level at which it is likely to be economically feasible to retrofit an existing product line.

Windows NT was evaluated at only C-2 and Trusted Solaris at only B-1 under the TCSEC criteria.

See here

--: EAL1: Functionally Tested
--: EAL2: Structurally Tested
--: EAL3: Methodically Tested and Checked
--: EAL4: Methodically Designed, Tested and Reviewed
--: EAL5: Semiformally Designed and Tested
--: EAL6: Semiformally Verified Design and Tested
--: EAL7: Formally Verified Design and Tested

From the US government report GAO-06-392: * {{cite paper | author = GAO | title = INFORMATION ASSURANCE: National Partnership Offers Benefits, but Faces Considerable Challenges | publisher = United States Government Accountability Office | version

Uses

desktop, server, or network gateway.
rack-mount configuration
provides a trusted backup/save tool.

Security

mandatory policies can not be disabled
STOP requires the mandatory sensitivity policy and supports mandatory integrity policy,
the sensitivity and integrity policies apply to all users and all objects on the system

--: sensitivity policy deals with preventing unauthorized disclosure an integrity policy deals with preventing unauthorized deletion or modification (such as the damage that a virus might attempt).

STOP provides

--: 16 hierarchical sensitivity levels,.
--: 64 non-hierarchical sensitivity categories,.
--: 8 hierarchical integrity levels,.
--: 16 non-hierarchical integrity categories.

Other

--: Identification and authentication Discretionary access control (DAC) A mandatory "subtype" policy, which allows some of the functionality of trusted systems which support a full "Type Enforcement" or "Domain-Type Enforcement" policy. Auditing of all security-relevant events and trusted tools to detect and analyze potential security violations. Trusted path, which allows a user asure s/he is interacting directly with the TSF during sensitive operations (Trojan Horses) Isolation, of the operating system code and data files from the activity of untrusted users and processes. Separation, of processes from one another Reference monitor functionality, so that no access can bypass scrutiny by the operating system. Strong separation of administrator, operator, and user roles using the mandatory integrity policy. Residual information (i.e., object reuse) mechanisms to prevent data scavenging. Trusted, evaluated tools for configuring the Self-testing of security mechanisms, on demand.
--: Exclusion of higher layer network services from the trusted security functions (TSF), so that the TSF is not susceptible to the publicly known vulnerabilities in those services.

10.22. System Architecture

Application Domain

--: Application is untrusted by default
--: Trusted software includes all security related functions (must bypass TSF).
--: Software development (C)
--: Trusted Databases

--: data can only be modified by user developed trusted processes, or
--: trusted Editors

10.23. Criticism

Users unable to modify software

Data locked in

Users have no control over data

Data is sealed - not moveable

Loss of anonymity
Practicality
Interoperability
Shutting out of competing products
Trust

10.24. Use Case

Protect data at rest
Money question
http://www.gnu.org/philosophy/can-you-trust.html

10.25. Questions

Who is trustworthy enough?

10.26. More Reading

http://www.eff.org/wp/trusted-computing-promise-and-risk