Docstoc

Computer Security

Document Sample
Computer Security Powered By Docstoc
					                 Trusted Computing/Platforms




Material on TCG is based on slide material from Dries Schellekens
http://www.esat.kuleuven.be/cosic/seminars/slides/Trusted_Platforms.ppt




2011/09/22- B. Smeets               EIT - Secure Sys & Applic - Trusted Systems   1
Overview
   Why trusted computing ?
   Intuitive model of trusted computing
   Hardware versus software
   Software secured execution environment:
         Java, STIP, .NET
         OSes and Virtualization: Linux LSM, SELinux
   Hardware secured execution environment: TrustZone
   Description of the two important trusted platforms: TCG and
    NGSCB
   Special trusted computing devices

2011/09/22- B. Smeets               EIT - Secure Sys & Applic - Trusted Systems   2
Why trusted computing: new security challenges
   Computing devices are becoming distributed, unsupervised,
    and physically exposed
         Computers on the Internet (with untrusted owners)
         Embedded devices (cars, home appliances)
         Mobile devices (cell phones, PDAs, laptops)
         Smart sensor devices


   Attackers may physically tamper with devices
         Invasive probing
         Non-invasive measurement
         Install malicious software
2011/09/22- B. Smeets                  EIT - Secure Sys & Applic - Trusted Systems   3
Benefits of trusted platform
   Less physical security for IT infrastructure
         Access point, base stations, servers
   Sensor and surveillance
         Can rely on the data that is received
   Electronic payments
         Correct amount, anonymous (to some extend)
   Digital Rights Management (DRM)
         Enforce copyright on content (music, video, programs, etc)
   Third-party (grid) computing
         Produce correct results
   More robust reputation in P2P
         Detect misbehaving users
2011/09/22- B. Smeets                       EIT - Secure Sys & Applic - Trusted Systems   4
From trusted computing to trusted platform
   Trusted Computing
         Needs that the (application) software can be trusted

                                 SW security: Not the subject of this
                                 lecture
         Needs that the underlying system can be trusted

                                  Trusted Platforms




2011/09/22- B. Smeets                 EIT - Secure Sys & Applic - Trusted Systems   5
What do we mean by trust here ?
   The first aspect of trust is that when trusted a system can
    operate on its own to do the right thing
         The system keeps its integrity


   The second aspect of trust is that it needs a mechanism by
    which trust can be given
         A procedure by which we can gain trust in a system




2011/09/22- B. Smeets                 EIT - Secure Sys & Applic - Trusted Systems   6
Intuitive models
   Open platform (e.g. PC, PDA, Android, Linux device)
         General purpose computing platform
         No a priori trust with third party


   Closed platform (e.g. ATM, set-top box, game console, satellite
    receiver, most mobile phones)
         Special purpose computing device
         Can authenticate itself to a remote party using a secret key and ensure
          well-behaved operation
         Hardware tamper resistance to protect the secret key (embedded
          during manufacturing)
2011/09/22- B. Smeets                 EIT - Secure Sys & Applic - Trusted Systems   7
Intuitive models cont‟d
Trusted computing combines best properties of

   Open: allow applications from many different sources to run on
    same platform

   Closed:
         Only ”known” software can execute
         remote parties can determine what software is running and whether to
          expect the platform to be well behaved
            • Done through attestation

2011/09/22- B. Smeets                    EIT - Secure Sys & Applic - Trusted Systems   8
Basic model for attestation (1/3)
   Certificate Chw (hw=hardware) on
         signing key Ksign
   Application A generates key pair PKA, SKA
   Certificate CA on
         PKA and hash of executable image of A using Ksign
   A attests its validity to a remote server by
         sending Chw and CA
         proving knowledge of SKA
   Remote server checks certificates and whether the application
    hash in CA is trusted
2011/09/22- B. Smeets                EIT - Secure Sys & Applic - Trusted Systems   9
Basic model for attestation (2/3)

        Chw:
        Ksign


                Application A:                                              SERVER
                                  Prove knowledge
                                   Prove & REPORT
                  imageA               of SKA
                 PKA, SKA


         CA:                                       Attestation
                1. PKA
                2. hash(imageA)
                  using Ksign




2011/09/22- B. Smeets                 EIT - Secure Sys & Applic - Trusted Systems    10
Basic model for attestation (2/3)
   Each layer of the platform is checked
         Hardware attests what OS is booted
         OS will attest what application it requires a key for and will only allow
          the use of that key by that given application



           Attestation is USED in TCG




2011/09/22- B. Smeets                  EIT - Secure Sys & Applic - Trusted Systems   11
Hardware vs Software
   Functionality in Hardware                     Functionality in Software
         hard to change                                Easy to change
         high performance possible                     Difficult to hold private keys




2011/09/22- B. Smeets                 EIT - Secure Sys & Applic - Trusted Systems   12
Trusted Systems in Software
   Possible but we have limitations



         owner of the device on which software runs should not be an attacker
          (he/she and the device ”work together”/”have the same interests”)

         Does not work when the device in the ”enemy‟s territory”




2011/09/22- B. Smeets                EIT - Secure Sys & Applic - Trusted Systems   13
OSes
   OSes come in many different versions; Linux, Windows X,
    Symbian, Palm-OS, etc

   Most simple OSes have no means to securely enforce (multi-
    user) access control

   Even if so
         Correct configuration of fullblown OS is not trivial
         Without protection user can attack system from ”below”


2011/09/22- B. Smeets                EIT - Secure Sys & Applic - Trusted Systems   14
OS for trusted computing
   Primary security objective of OS in a trusted platform = secure
    isolation
         Mainstream OS (e.g. Windows, Linux)
            • Large and complex code base
            • Optimized for ease of use, performance and reliability
         Trusted OS (e.g. Trusted Solaris, SE-Linux, SPEF)
            • Not user friendly (because of security policy)
   Solutions to have best of both
         Hypervisor (also called Virtual Machine Monitor (VMM))
            • attestation through virtual device
         Change existing hardware
            • attestation done by hardware module
            • add secure execution mode to CPU
2011/09/22- B. Smeets                       EIT - Secure Sys & Applic - Trusted Systems   15
OS environment setup for a trusted platform


                                   User
                                  space          User         User
                                                 space        space                     trusted
                                                                               User
      Userspace                   kernel                                       space
                                                                                          User
                                                                                         space
                                                 kernel       kernel
                              virtualization

                                                                                        trusted
         kernel              kernel               hypervisor                   kernel
                                                                                         kernel

    Normal OS             Virtual Machine          Hypervisor                      CPU with
  (Windows, Linux       (VMWare, Java VM)                                        trusted mode
                                                                                (e.g.TrustZone)
       SE Linux)



2011/09/22- B. Smeets                  EIT - Secure Sys & Applic - Trusted Systems          16
Virtualization
   Abstraction of computer resources
   Pioneered by IBM to keep using legacy system solutions on
    new hardware without rewriting code
   Turned up to have stability and security benefits (isolation)
          (at the expense of performance)
   There are many ways to do this and there exist therefore many
    different types of products. Main distinction:
         Full/pure virtualization: ensure that sensitive instructions are not
          executable within the virtual machine, but instead invoke the
          hypervisor: needs hardware support
         Impure virtualization: remove sensitive instructions from the virtual
          machine and replace them with virtualization code.
2011/09/22- B. Smeets                  EIT - Secure Sys & Applic - Trusted Systems   17
Hypervisors and micro Kernels
     Execute in priveledge mode
     Schedule the systems(OSs) that execute on it


                           Non priveledged                      Userspace



                                                                     OS


                                                             hypervisor
                               priveledged

                                                               processor


2011/09/22- B. Smeets          EIT - Secure Sys & Applic - Trusted Systems   18
Pure Virtualization
   Most instructions are executed directly on the hardware.
   All senstive instructions are priveledged. They are trapped and
    instead executed by the hypervisor that runs in priveledged
    space (kernel mode, superuser mode, etc).
   Needs hardware support (Modern main CPUs have this)




2011/09/22- B. Smeets          EIT - Secure Sys & Applic - Trusted Systems   19
Impure Virtualization
   Most instructions are executed directly on the hardware.
   All senstive instructions rewritten (e.g. during load time or
    during porting (para virtualization)): either trap to hypervisor or
    jump to a user-level emulation code




2011/09/22- B. Smeets            EIT - Secure Sys & Applic - Trusted Systems   20
Example of a trusted microkernel: L4
   Used in various Qualcomm phone, available for Linux and
    Symbian

   Academic work ongoing

   Free to use

   Commercial: OpenKernel Labs


2011/09/22- B. Smeets        EIT - Secure Sys & Applic - Trusted Systems   21
                        Java as trusted execution environment

                                   Trusted systems in SW




2011/09/22- B. Smeets          EIT - Secure Sys & Applic - Trusted Systems   22
Outline
   components of Java
   Java security models
   main components of the Java security architecture
         class loaders
         byte code verification
         the Security Manager




2011/09/22- B. Smeets              EIT - Secure Sys & Applic - Trusted Systems   23
The Java Virtual Machine (JVM)
                                                                                                         JVM

                                                                             heap
                              class loader           class file                                  JIT
              network
                                instance              verifier
                                                                         class
                                                                         area
                local         primordial                                                      execution
                             class loader                                                      engine
         untrusted classes

          trusted classes
                             native method                              native method          Security
          native methods         loader                                      area              Manager




                                                           operating system



                                                                                           native code
                                                                                           Java code

2011/09/22- B. Smeets                        EIT - Secure Sys & Applic - Trusted Systems               27
JVM cont‟d
   class file verifier
         checks untrusted class files
            • size and structure of the class file
            • bytecode integrity (references, illegal operations, …)
            • some run-time characteristics (e.g., stack overflow)
         a class is accepted only if it passes the test




2011/09/22- B. Smeets                       EIT - Secure Sys & Applic - Trusted Systems   29
JVM cont‟d
   Security Manager
         enforces access control at run-time (e.g., prevents applets from
          reading or writing to the file system, accessing the network, printing,
          ...)
         application developers can implement their own Security Manager
         or use the policy based SM implementation provided by the JDK




2011/09/22- B. Smeets                  EIT - Secure Sys & Applic - Trusted Systems   32
Java security models
   the need for Java security
   the sandbox (Java 1.0)
   the concept of trusted code (Java 1.1)
   fine grained access control (Java 2)




2011/09/22- B. Smeets          EIT - Secure Sys & Applic - Trusted Systems   33
The sandbox
   idea: limit the resources that can be accessed by applets
   (this creates an execution sandbox)                  JVM

                                        local code                                sandbox

                                      remote code
                                         (applets)


                                                                         resources
      introduced in Java 1.0
      local code had unrestricted access to resources
      downloaded code (applet) was restricted to the sandbox
            cannot access the local file system
            cannot access system resources,
            can establish a network connection only with its originating web server
2011/09/22- B. Smeets                       EIT - Secure Sys & Applic - Trusted Systems     34
The concept of trusted code
       idea: applets that originate from a trusted source could be trusted
                                                                             JVM
                                        local code

                                                                     signed and     sandbox
                                     remote code                     trusted
                                        (applets)                    unsigned, or
                                                                      signed and
                                                                        untrusted

          introduced in Java 1.1                              resources
          applets could be digitally signed
          unsigned applets and applets signed by an untrusted principal were
           restricted to the sandbox
          local applications and applets signed by a trusted principal had
           unrestricted access to resources
2011/09/22- B. Smeets                EIT - Secure Sys & Applic - Trusted Systems              35
Fine grained access control
       idea: every code (remote or local) has access to the system resources
       based on what is                                                     JVM

       defined in a policy file
                    local or remote code
                                                   class loaders
                    (signed or unsigned)



                                      policy
                                       file
                                                                  resources
          introduced in Java 2
          a protection domain is an association of a code source and the permissions
           granted
          the code source consists of a URL and an optional signature
          permissions granted to a code source are specified in the policy file
                   grant CodeBase “http://java.sun.com”, SignedBy “Sun” {
                     permission java.io.FilePermission “${user.home}${/}*”, “read, write”;
                     permission java.net.SocketPermission “localhost:1024-”, “listen”;};
2011/09/22- B. Smeets                           EIT - Secure Sys & Applic - Trusted Systems   36
The three pillars of Java security
   the Security Manager
   class loader
   the bytecode verifier




2011/09/22- B. Smeets       EIT - Secure Sys & Applic - Trusted Systems   37
Class loaders
   separate name spaces
      classes loaded by a class loader instance belong to the same name space

      since classes with the same name may exist on different Web sites, different Web
        sites are handled by different instances of the applet class loader
      a class in one name space cannot access a class in another name space

       classes from different Web sites cannot access each other

   establish the protection domain (set of permissions) for a loaded class
   enforce a search order that prevents trusted system classes from being replaced by
    classes from less trusted sources…




2011/09/22- B. Smeets                   EIT - Secure Sys & Applic - Trusted Systems   40
Class loading task delegation
                        primordial class loader
                                                        4a       loads class from
                            (searches on
                         the boot class path)                    boot class path


                           3            4b failure

                        a class loader instance
                        started at JVM startup          5a       loads class from
                             (searches on                        class path
                            the class path)

                           2             5b success / failure

                        a class loader instance
                        associated with a URL           6
                                                                loads class from URL
                         (searches on the site
                         specified by the URL)
                            1
                        class request
2011/09/22- B. Smeets                          EIT - Secure Sys & Applic - Trusted Systems   42
Byte code verifier
   performs static analysis of the bytecode
      syntactic analysis
          • all arguments to flow control instructions must cause branches to the start of a
              valid instruction
          • all references to local variables must be legal
          • all references to the constant pool must be to an entry of appropriate type
          • all opcodes must have the correct number of arguments
          • exception handlers must start at the beginning of a valid instruction
          • …
      data flow analysis
          • attempts to reconstruct the behavior of the code at run time without actually
              running the code
          • keeps track only of types not the actual values in the stack and in local variables
      it is theoretically impossible to identify all problems that may occur at run time with
        static analysis
2011/09/22- B. Smeets                      EIT - Secure Sys & Applic - Trusted Systems   43
Java‟s impact
   The Java system has been an example for many other
    languages and execution environments.
    E.g.

         ActiveX
         .Net
         STIP
         Dalvik (Android)




2011/09/22- B. Smeets        EIT - Secure Sys & Applic - Trusted Systems   44
Comparison with ActiveX
   ActiveX controls contain native code
   security is based on the concept of trusted code
         ActiveX controls are signed
         if signer is trusted, then the control is trusted too
         once trusted, the control has full access to resources
   not suitable to run untrusted code
         no sandbox mechanism




2011/09/22- B. Smeets                 EIT - Secure Sys & Applic - Trusted Systems   45
Comparison with STIP
   STIP is pretty much like Java
   STIP needs much smaller VM
   STIP is not under control of SUN (or Microsoft)
   STIP is better on access control
   STIPlets can be executed directly from ROM/(NOR) Flash
    memory (no need to load first into RAM)
   STIP is for small devices (e.g. smart card terminals)
   STIP is limited in MMI APIs

http://www.globalplatform.org/uploads/STIP_WhitePaper.pdf

2011/09/22- B. Smeets        EIT - Secure Sys & Applic - Trusted Systems   46
                                                                 SELinux

                            Trusted systems in SW




2011/09/22- B. Smeets   EIT - Secure Sys & Applic - Trusted Systems        48
Example of a trusted OS: SELinux
Motivation

   Discretionary Access Control (DAC) in Linux provides not
    enough choices for controlling objects.

   Mandatory Access Control (MAC) allows you to define
    permissions for how all processes (called subjects) interact with
    other parts of the system such as files, devices, sockets, ports,
    and other processes (called objects in SELinux).


2011/09/22- B. Smeets          EIT - Secure Sys & Applic - Trusted Systems   49
 SELinux Development History
 Primarily developed by the US National Security Agency
 SELinux implements Flask
                                            2.4 Linux
                                              Kernel
                                             (patch)
                                                            2.6 Linux
    LOCK                                                      Kernel
                                    2.2 Linux                mainline Full network
 (early Type                          Kernel
Enforcement)                                              LSM           labeling
                                     (patch)

    1985                               1999 2001 2002 2003                            2006

        DTMach/DTOS

                         Utah Fluke/Flask




 2011/09/22- B. Smeets                      EIT - Secure Sys & Applic - Trusted Systems      50
Security goal for SELinux
   General: Minimize the effect of malicious code and exploits
           - ”Sandboxing” programs and data
           - control access rights, minimize the privileges




2011/09/22- B. Smeets                 EIT - Secure Sys & Applic - Trusted Systems   51
     Concepts




2011/09/22- B. Smeets   EIT - Secure Sys & Applic - Trusted Systems   52
Type Enforcement & Domain Transition

      Domain
       Domain defines what process can do.
      Type
       A type is assigned to an object and determines who gets to access
       that object.
      Domain Transition
       when a process invoke another process
      Type Enforcement
       when a object is accessed



2011/09/22- B. Smeets              EIT - Secure Sys & Applic - Trusted Systems   53
Users & Roles
   First and second component of a security context
   SELinux usernames and DAC usernames are not synonymous
         Semanage is used to maintain mappings of DAC to SELinux
          usernames.


   Roles are collections of types geared towards a purpose
   Roles can be used to further restrict actions on the system

   SELinux usernames are granted roles in the system


2011/09/22- B. Smeets              EIT - Secure Sys & Applic - Trusted Systems   54
Domain Transitions in SELinux
   Analogous to SetUID programs in ordinary Unix
   Alice running as user_t (untrusted user) needs to change her
    password. How ?
         allow user_t passwd_exec_t : file {getattr execute}
         allow passwd_t passwd_exec_t : file entrypoint
         allow user_t passwd_t : process transition
         What does this solve?
            Restricts trusted domain passwd_t and allows user_t to transition to
          it.


   Implicit domain transitions provided via type transition.
2011/09/22- B. Smeets                 EIT - Secure Sys & Applic - Trusted Systems   55
Multi-Level Security (MLS)
   MLS portion of Security Context is composed of 4 parts
         Low/High
         Sensitivity/Category


   Includes syntax to define dominance of security levels
   Subjects with range of levels considered trusted subjects

   Implements a variation of Bell-La Padula



2011/09/22- B. Smeets            EIT - Secure Sys & Applic - Trusted Systems   56
Type Enforcement (TE)
   Object(s): items in a system that are acted upon (files, IPC, sockets,
    etc….)
   Subject(s): process that are requesting access to an object
         All Objects and Subjects contain a security context
   Security Context(s): are composed of four parts
   All Security Context components are checked against the policy to see if
    access is allowed.
   Type is the base component while role and user are used to further
    restrict type enforcement



2011/09/22- B. Smeets                 EIT - Secure Sys & Applic - Trusted Systems   57
The security context is made up of 3 or 4 components
                                                           http://fedoraproject.org/wiki/SELinux/SecurityContext#Security_Context
     separated by “:”
     Component 1: Users
        This component can be thought of as a way of grouping roles. SELinux Users can have
          multiple roles that they can reach, and then in those roles they can reach multiple types. Three
          users that you will usually see on the system are "user_u", "system_u" and root. Roles by
          convention end with a "_u“ except for root.
     Component 2: Roles
        This field is only really relevant on processes or domains. The role field on a file is always
          object_r, and really has no meaning other than as a place holder. On a process you would
          usually see a role like system_r or sysadm_r. Roles by convention end with a "_r".
     Component 3: Types
        The 3rd component of the security context is the Type component, for example /usr/sbin/httpd
          is labeled with a type of “httpd_exec_t".
        This field is the heart of SELinux Type Enforcement. Most of the policy rules in SELinux
          revolve around what subject types have what access to which object types. By convention
          roles always ends in a "_t".
     Component 4: MLS Component
        Is not always supported in all SELinux versions
        Unfortunately this field can contain a ":". The syntax of this field can look something like s0-
          s15:c1,c2. Most files by default are labeled s0, sometimes referred to as SystemLow.
2011/09/22- B. Smeets                                   EIT - Secure Sys & Applic - Trusted Systems                   58
Security Contexts

      system_u: object_r:                    passwd_exec_t: s0: c0.c2 -s2: c0.c1




        user:role:type:sensitivity[:category,…][-sensitivity[:category,…]]
         1       2      3                               4



             •Fortunately SELinux provides a translation library (libsetrans) that replaces the codes
             field 4 with a more human readable form. So something like s0:c1,c2 might be show
             up to the user as PatientRecord,CompanyConfidential. „

             •On a targeted or strict policy machine s0 translates to "", so almost all files will not
             even show the fourth field.
2011/09/22- B. Smeets                             EIT - Secure Sys & Applic - Trusted Systems            59
     Architecture




2011/09/22- B. Smeets   EIT - Secure Sys & Applic - Trusted Systems   61
LSM (Linux Security Module)
   Kernel framework for security modules
   Provides a set of hooks to implement further security checks
   Usually placed after existing DAC checks and before
    resource access
   Implications?
         SELinux check is not called if the DAC fails
         Makes auditing difficult at times.




2011/09/22- B. Smeets                 EIT - Secure Sys & Applic - Trusted Systems   62
SELinux LSM Module
                                                                                    Policy
                                                                                  Management

           User Space                                                              Interface

           Kernel Space
                                          Selinux Filesystem



 Various
 Kernel                   Access       Cache Miss              Security Server
                           Vector                             (Policy Rules and
 Object           LSM                   Yes or No?
                           Cache                            Access Decision Logic)
Managers         Hooks




                                           SELinux LSM Module
2011/09/22- B. Smeets               EIT - Secure Sys & Applic - Trusted Systems           63
    SELinux Policy Language




2011/09/22- B. Smeets   EIT - Secure Sys & Applic - Trusted Systems   67
Object Classes
   Represents resources of a certain kind
   Policy must include declarations for all object classes
   Classes
         File related (blk_file,chr_file,dir,fd …)
         Network related (socket, packet_socket, rawip_socket, …)
         IPC related (ipc, msg, msgq, sem, shm)
         Misc Classes (capability, process, security, system)




2011/09/22- B. Smeets               EIT - Secure Sys & Applic - Trusted Systems   68
Ex: Motorola SElinux Policy
(from http://wiki.openezx.org/Rokr_E2)


The ROKR 33P build's security                         Processes:
policy can be found in the binary                        Defined Domains:
file /etc/acpolicy.cfg.                                  1: moto_domain
Motorola Access Control Policy                                 •   /bin/fakelogin3
                                                               •   /usr/SYSqtapp/drm/drmapp*
Here is a summary for user 'root':                             •   /usr/sbin/in.telnetd
                                                               •   /bin/bash
    Filesystem:                                               •   /bin/sh
       /usr/* protected resource (r-x)                        •   /bin/ash
       /bin/* protected resource (r-x)                        •   /usr/SYSqtapp/am/am*
       /sbin/* protected resource (r-x)                       •   /usr/SYSqtapp/phone/*
       /etc/* protected resource (r-x)                        •   /etc/ac_getflexbit
       /.backup/* protected resource (r-x)                 2: carrier
                                                            3: trusted
                                                            4: Untrusted

2011/09/22- B. Smeets                     EIT - Secure Sys & Applic - Trusted Systems          71
Reference Policies
   Maintained by NSA and FC Mailing Lists
   Compiles into three versions
        Strict, Targeted, MLS
   Statistic:
         Version .18
       Object Classes 55

       Common Permissions 3, Permission 205

       Types 1589

       allow 372755, auditallow 12, dontaudit 238663

       type_transition 2657, type_change 68

       roles 6, RBAC allow 6, role_transition 97, users 3

       bools 70
2011/09/22- B. Smeets               EIT - Secure Sys & Applic - Trusted Systems   75
Distributions
   Fedora Core 3 and later
   Debian
   Gentoo
   SuSe
   SE-BSD
   SE-MACH




2011/09/22- B. Smeets         EIT - Secure Sys & Applic - Trusted Systems   78
Alternatives
   DAC
         execute every program as a new user creates a ”lightweight” sandbox (e.g. Android). Still
          security issues with setuid and root.

   AppArmor and Tomoyo
         AppArmor was originally developed because SELinux was viewed as too complex for typical
          users to manage
         Implements a pathbased MAC (Unlike SELinux, which is based on applying labels to files,
          AppArmor works with file paths)
         Does not require xattr for filesystem
         AppArmor in SUSE and Ubunto

   Simple MAC Kernel (SMACK)
          Smack implements mandatory access control (MAC) using labels attached to tasks and data
          containers, including files, SVIPC, and other tasks. Smack is a kernel based scheme that
          requires an absolute minimum of application support and a very small amount of configuration
          data.


2011/09/22- B. Smeets                          EIT - Secure Sys & Applic - Trusted Systems       79
Alternatives cont‟d
   SPEF
      Part of LIMO initiative

   Virtualisation
      Creates isolated domain

   grsecurity (http://www.grsecurity.net/)
      A set of patches to Linux. In addition grsecurity provides full role-based access
        control




2011/09/22- B. Smeets                     EIT - Secure Sys & Applic - Trusted Systems      80
                                                                      TCG




2011/09/22- B. Smeets   EIT - Secure Sys & Applic - Trusted Systems         81
Changes to existing platforms
   Trusted Computing Group (TCG)
         Formally called TCPA (Trusted Computing Platform Alliance)
         Focus on: PC, Server devices
         2006: Simplified approach for mobile devices
   Microsoft Palladium
         Renamed to Next-Generation Secure Computing Base (NGSCB)
         Intel LaGrande Technology
   ARM TrustZone



2011/09/22- B. Smeets               EIT - Secure Sys & Applic - Trusted Systems   82
TCG
   Founded in 1999 by Compaq, HP, IBM, Intel and Microsoft
   Currently more than 200 members
   Changes to platform
         Extra for advanced devices: Trusted Platform Module (TPM)
         Extra for mobile devices: MTM
         Software changes: BIOS + OS
   Main properties
         Secure bootstrap
         Platform attestation
         Protected storage

2011/09/22- B. Smeets               EIT - Secure Sys & Applic - Trusted Systems   83
The three basic functions in a trusted platform
   Protected Capabilities
    Protected capabilities is a set of commands that grant the user issuing the
    command access to protected locations, memory (storage), registers, etc.

   Attestation
    Attestation is the process of verifying the accuracy of information and the
    characteristics of the TPMs current state.

   Integrity Measurement and Reporting
    Integrity measurement is the process of obtaining metrics of the platform
    characteristics and storing the information digest in a Platform
    Configuration Register (PCR). Integrity reporting is to attest the integrity
    measurements that are recorded in the PCR register.
2011/09/22- B. Smeets                EIT - Secure Sys & Applic - Trusted Systems   84
TCG Architecture (typically PC or Server)




2011/09/22- B. Smeets    EIT - Secure Sys & Applic - Trusted Systems   85
Trusted Platform Module (TPM)




2011/09/22- B. Smeets   EIT - Secure Sys & Applic - Trusted Systems   86
Trusted Platform Module (TPM)

 Asymmetric key generation          Cryptographic operations
                                        Hashing: SHA-1, HMAC
 Signing and encryption
                                        Random number generator
 Random number generator
                                        Asymmetric key generation: RSA (512, 1024,
                                         2048)
 PCR registers(≥16)                     Asymmetric encryption/ decryption: RSA
                                        Symmetric encryption/ decryption: DES,
        Hash            HMAC             3DES (AES)
                                    PCR Registers (≥16)
I/O       Processor     Memory
                                    Tamper resistant (hash and key) storage
Non-volatile memory
(≥1280) bytes
TPM
2011/09/22- B. Smeets            EIT - Secure Sys & Applic - Trusted Systems   87
  Commercial TMP example - Infineon




2011/09/22- B. Smeets   EIT - Secure Sys & Applic - Trusted Systems   88
The CRTM
   The CRTM is the a priori trusted code that is part of the platform
    credential. In the Static RTM Model, this MUST be the very first
    piece of code executed on power on or upon reset of the server
    or complete physical hardware environment.




2011/09/22- B. Smeets           EIT - Secure Sys & Applic - Trusted Systems   89
Trusted Building Block (TBB)
   The combination of the CRTM, TPM function, connection of the
    CRTM to the system/platform, and the connection (or binding)
    of a TPM to the system/platform makes up the TBB.
   Trust in the connection of the CRTM to the TPM is transitive,
    and relies upon trust in the CRTM connection to the
    system/platform and in the TPM connection to the
    system/platform.
   Server platforms may differ from other platforms in that TPM
    functionality may be physically distributed within the platform.
    However, the TBB encompasses the RTM

2011/09/22- B. Smeets          EIT - Secure Sys & Applic - Trusted Systems   90
The basic TCG idea

                                 4       OS code
                                                                     3




                                                                                  Measurement flow
                Execution flow




                                 2    OS loader code
                                                                     1
execute                                                                                              measure


                                        CRTM code


                                     TBB + roots of trust
2011/09/22- B. Smeets                        EIT - Secure Sys & Applic - Trusted Systems                 91
BOOT Process with TPM




1.    The Root of Trust for Measurement          6.     OSLoader is executed.
      (RTM) measures the BIOS metric.            7.     OS metric is measured.
2.    Measured value is reported to the          8.     Measured value is reported.
      Trusted Platform Module (TPM).             9.     OS is executed.
3.    BIOS is executed.                          10.    An application is measured.
4.    Operating System (OS) Loader metric        11.    Measured value is reported.
      is measured.
                                                 12.    Application is executed
5.    Measured value is reported.

2011/09/22- B. Smeets                  EIT - Secure Sys & Applic - Trusted Systems    92
Secure bootstrap: secure vs authenticated boot
   Integrity metric
   Platform Configuration Register (PCR)
   Two methods of booting
         Secure Boot: boot can be halted
         Authenticated Boot: just reporting




2011/09/22- B. Smeets                 EIT - Secure Sys & Applic - Trusted Systems   93
Secure bootstrap cont‟d: PCRs and measuring
      Extending a PCR
       PCR_Extend(n,data): PCR[n]SHA1(PCR[n] || data)
      When booting
      1.    Reset PCRs
      2.    PCR_Extend(n,<Bios Code>)
      3.    PCR_Extend(n,<MBR>)
      4.    etc
                               Platform Configuration Register
                        extended value                       present value
                                                                                        measured values
                                   Hash            Concatenate
                        TPM

2011/09/22- B. Smeets                     EIT - Secure Sys & Applic - Trusted Systems           94
TCG: Attestation
   Integrity reporting: report the value of the PCR
   Challenge-response protocol

          Challenger            nonce
                                                  Trusted Platform Agent

                                                                      TPM
                        SignID(nonce, PCR, log), CID




   TPM Identities (pseudonyms)
         Endorsement certificate embedded in TPM
         Privacy CA
         Use different identity for every challenger
2011/09/22- B. Smeets                      EIT - Secure Sys & Applic - Trusted Systems   95
Protected storage
   Smartcard alike
         Persistent, secure storage of keys
         Not 100 % hardware tamper resistant
   “Sealing”: binds data to a certain value of the PCR
         The TPM can only decrypt (unseal) if the PCR value is the same as
          when encryption happened (seal)
   Management: migration, backup




2011/09/22- B. Smeets                EIT - Secure Sys & Applic - Trusted Systems   97
TCG/TPM Issues
   Often seen as DRM enabler ( no longer true)
   Privacy issues
         TPM has unique embedded key
         Get pseudonyms in anonymous way (e.g. anonymous credentials)
   User loses control over own computer
         Secure boot: refuse to boot own compiled open source kernel
         Disable reverse engineering: need for hardware hack
   In a mobile device/phone we have multiple-stake holders
   TPM is complex
                                         Mobile Trusted Module (MTM)

2011/09/22- B. Smeets               EIT - Secure Sys & Applic - Trusted Systems   98
TCG/TPM Issues
   Current TPM cannot be remote managed.

         IT-departments do not like this. Hard to use


   Integration of TPM in a product is not the same for different
    computer vendors (even true for PC/laptops)




2011/09/22- B. Smeets                 EIT - Secure Sys & Applic - Trusted Systems   99
Mobile Trusted Module (MTM)
   The purpose of the mobile phone architecture was to support multiple
    stakeholders in a single device.

   If the Mobile Trusted Module (MTM) was a conventional TCG platform,
    then the user could disable other stakeholder‟s interest by disabling the
    MTM.

   The result of this is an architecture that uses a more general description of
    a trusted platform, “engines”. Each engine supports a separate
    stakeholder and the stakeholder has complete control over the engine



2011/09/22- B. Smeets               EIT - Secure Sys & Applic - Trusted Systems   100
Stakeholders in a phone
   Device Owner:
    Protect personal data and m-commerce
    transactions. MTM use should be optional for the Device Owner, but
    mandatory for the other stakeholders.

   Device Manufacturer:
    Ensure that communication inside and outside the device is protected from
    eavesdropping and manipulation.

   Service Provider:
    Protect the services that are offered on the platform, enforce billing
    policies and SIM-lock.
2011/09/22- B. Smeets                EIT - Secure Sys & Applic - Trusted Systems   101
Mobile Trusted Module (MTM)




                                       •Root of Trust for Storage



                                       •Root of Trust for Reporting




2011/09/22- B. Smeets   EIT - Secure Sys & Applic - Trusted Systems   102
Next Generation Secure Computing Base (NGSCB)
History:
 During1998 one started to work on making Microsoft Windows a
  secure OS

   On June 2002 Microsoft revealed its first proposal under the
    codename Palladium as part of their Trusted Computing (TC)
    initiative.

   Both changed names and Palladium became Next Generation
    Secure Computing Base (NGSCB) and Trusted Computing
    became Trustworthy Computing.
2011/09/22- B. Smeets         EIT - Secure Sys & Applic - Trusted Systems   103
NGSCB: redefining its ambitions
    The initial plans for NGSCB where very ambitious but where finally
     abandoned somewhere around 2007-2008:
    ” Our original approach was to create a new secure computing base
     that would run parallel to the regular Windows environment. This
     environment would provide features such as strong process
     isolation, sealed storage, secure path to and from the user, and
     attestation. This architectural approach would have required that
     applications be rewritten to take advantage of the new secure
     computing base.
     While our customers said they liked the enhanced level of security
     offered in the original NGSCB architecture, they needed higher
     availability, better performance, and compatibility with existing
     applications. We heard strong feedback requesting that we meet
     these critical new requirements, as customers were concerned that
     having to rewrite all of their applications would hinder adoption of
     NGSCB”
2011/09/22- B. Smeets             EIT - Secure Sys & Applic - Trusted Systems   104
NCSB: delivered (in Vista)
   A hardware based security feature in Vista called Secure
    Startup. This Secure Startup utilizes a TPM (version 1.2).
   Volume encryption through a system called Bitlocker drive
    encryption




2011/09/22- B. Smeets          EIT - Secure Sys & Applic - Trusted Systems   105
Bitlocker (1/3)
   AES in CBC mode with Elephant diffuser
   Key escrow via Active Directory
   Three different modes are supported
         Transparent operation mode (with TPM): The key used for the disk
          encryption is sealed by the TPM and will only be released to the OS
          loader code if the early boot successfully verified. The boot
          components of BitLocker do a Static Root of Trust Measurement.
         User authentication mode (with TPM): This mode requires that the
          user provide some authentication to the pre-boot environment in order
          to be able to boot the OS. Two authentication modes are supported: a
          pre-boot PIN entered by the user, or a USB key.
         USB Key Mode: The user must insert a USB device that contains a
          startup key into the computer to be able to boot the protected OS.
2011/09/22- B. Smeets                EIT - Secure Sys & Applic - Trusted Systems   106
AES+CBC with Elephant
   AES CBC: cost 20 cycles per byte on Pentium4
   Diffusers: cost 10 cycles per byte
   Microsoft reports overall penalty of 5%
    A diffuser




    B diffuser




2011/09/22- B. Smeets        EIT - Secure Sys & Applic - Trusted Systems   107
Bitlocker (2/3)
   Combinations
         TPM only
         TPM + PIN
         TPM + PIN + USB Key
         TPM + USB Key
         USB Key
   At least two NTFS volumes needed: one for the OS and another
    unencrypted to boot the OS from.



2011/09/22- B. Smeets           EIT - Secure Sys & Applic - Trusted Systems   108
Bitlocker (3/3)
   BitLocker encryption is transparent to OS
         Bitlocker decrypts on-disk files before the OS has loaded. Therefore,
          all file operations occur from the OS perspective as if there is no
          encryption.
         Protection of the files from processes/users within the operating
          system can only be performed using encryption software that operates
          within Windows, such as Encrypting File System.




2011/09/22- B. Smeets                EIT - Secure Sys & Applic - Trusted Systems   109
ARM TrustZone
   A special mode of operation for the ARM11 processor
   Divides the SoC into “normal world” and “secure world”
                        Normal world                Secure world




2011/09/22- B. Smeets                  EIT - Secure Sys & Applic - Trusted Systems   110
TrustZone – what can it be used for
   Protect the essential assets of a device
         secret data and keys,
         access to sensitive peripherals or memory
   Run security-sensitive operations
         cryptographic operations
         key management.
   Enables richer security applications
         DRM
         electronic payment
         digital signature schemes.
   Dynamically load and remove security services.
2011/09/22- B. Smeets                  EIT - Secure Sys & Applic - Trusted Systems   111
Basic idea
   Introduce an NS-bit
         use this bit to tag secure data throughout system
            • Buses
            • cache
            • pages


   Monitor
         manages the NS-bit
         manages transition in & out of security mode
         Small fixed API


2011/09/22- B. Smeets                 EIT - Secure Sys & Applic - Trusted Systems   112
Switching from Normal to Secure

                        userspace                                      userspace
              Normal                           Secure
             application                       Service


                                Monitor

                Normal                         Secure                   Secure           Secure
                 OS                            Kernel                   drivers          device

                                                                                          Boot
    priviledged                       priviledged                                        loader

       Normal                                        Securel
2011/09/22- B. Smeets                      EIT - Secure Sys & Applic - Trusted Systems      113
Traditional secure app environment




                                          application
            application

                          application




                                                        application

                                                                        application
                                                                                      userspace

                                                                                      priviledged



                                        Platform
                                          OS

           Trusted Code Base
2011/09/22- B. Smeets                                                 EIT - Secure Sys & Applic - Trusted Systems   114
TrustZone application environment
                                                                       TrustZone NS bit ”wall”




                                          application
            application

                          application




                                                         application

                                                                         application




                                                                                                   sec appl

                                                                                                                sec appl
                                                                                                                           userspace

                                                                                                                           priviledged


                                        Platform                                                              Secure
                                          OS                                                                  kernel
                                                                                             Trusted Code Base
                                                        Fixed                                                 Fixed
       Normal                                           entry                                                 entry        Secure
                                                        points                         monitor                points
2011/09/22- B. Smeets                                                  EIT - Secure Sys & Applic - Trusted Systems             115
TrustZone uses Hardware features - Example System




2011/09/22- B. Smeets   EIT - Secure Sys & Applic - Trusted Systems   116
Special trusted computing devices
   Secure Cryptoprocessors
         Dedicated microprocessor system with physical protection features
            •   Tamper-detecting and tamper-evident containment.
            •   Automatic zeroization of secrets in the event of tampering.
            •   Chain of trust boot-loader which authenticates the operating system before loading it.
            •   Chain of trust operating system which authenticates application software before loading it.
            •   Hardware-based capability registers, implementing a one-way privilege separation model.
            •   Possibly battery backup
         Smart cards
         History: IBM 4758 PCI Cryptographic processor (PKCS#11 interface)
            Attacked 2001 by PhD students at Cambridge University
            replaced by IBM 4764
   Security Modules:
         like Secure cryptoprocessors but more capable as system.
2011/09/22- B. Smeets                            EIT - Secure Sys & Applic - Trusted Systems       117
HSM (Hardware (or Host) Security Modules)
   Special Computers with high-grade protection with purpose to
    to store critical information and keys

   Some can be small – pci card/smartcard like
   Some can be large – desktop box like

   Interfaces
         often non-standard
         PKCS#11


2011/09/22- B. Smeets          EIT - Secure Sys & Applic - Trusted Systems   118

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:9
posted:10/14/2011
language:English
pages:96
gjmpzlaezgx gjmpzlaezgx
About