code signing with cpk

1

Code SigningGuan Zhi <guanzhi@infosec.pku.edu.cn>

Nov. 7, 2007 - Dec. 19, 2007

Introduction

• Code signing is the process of digitally signing executables and scripts to confirm the software author and guarantee that the code has not been altered.

• All sorts of code should be signed, including tools, applications, scripts, libraries, plug-ins, and other “code-like” data.

2

Targets

• Ensure the integrity of the code; that it has not been altered.

• Identify the code as coming from a specific source (the vendor or signer).

• Determine whether the code is trustworthy for a specific purpose (for example, to access a keychain, or parent control).

3

Signed Code Includes

• A unique identifier, used to identify the code or to determine to which groups or categories the code belongs.

• A collection of checksums of the various parts of the program, such as the identifier, the main executable, the resource files.

• A digital signature, which signs the seal to guarantee its integrity.

4

What It can do

• Content Source: End users can confirm that the software really comes from the publisher who signed it.

• Content Integrity: End users can verify that the software has not been altered or corrupted since it was signed.

5

What It cannot do

• It can’t guarantee that the code is free of security vulnerabilities.

• It can’t guarantee that a program will not load unsafe or altered code—such as untrusted plug-ins—during execution.

• It can’t determine how much to “trust” the code.

• Attacks from administrator.

6

Other Disadvantages

• The user is likely to be bothered with additional dialog boxes and prompts for unsigned code that they don’t see with signed code, and unsigned code might not work as expected with some system components.

• Computation and storage overhead.

7

Architecture

exec()

sys_execve()

LSM Hook CodesignKernel Module

CodesignUser-spaceDaemon

Netlink Socket

True/False

mmap()

Enterprise Architecture

CheckEngine

Intranet

Policy DB

Kernel Module

Daemon

Host

Kernel Module

Daemon

Host

Kernel Module

Daemon

Host

host root host root host root

enterprise admin

Components

• Codesign Tool: used to create, check, and display code signatures.

• Kernel Module: Implement LSM (Linux Security Module) hook to check the signature in ELF.

• User-space Daemon: Do the checking, called by kernel module.

10

User vs Kernel

What user-space daemons can do but kernel modules cannot:

• Perform a long-running computation, block while waiting for an event;

• Access file system, network and devices;

• Get interactive input from user or pop up GUI windows

11

User & Kernel

• Splitting the implementation between kernel and user space is quite common in Linux.

• Only the most essential and performance-critical code are placed in the kernel.

• Other things, such as GUI, management and control code, typically are programmed as user-space applications.

12

How to Communicate?

• IPC between kernel and user space:

- system calls,

- ioctl

- proc filesystem

- netlink socket

13

Netlink Socket

• Full-duplex communication link by way of standard socket APIs for user-space processes and a special kernel API for kernel modules.

• Address family AF_NETLINK (include/linux/netlink.h).

14

User-Space APIs

• to do: standard socket API

15

Kernel-Space APIs

• To do: view the kernel code.

16

Linux Security Module

• Linux Security Module (LSM) is a general access-control framework of kernel hooks that would allow security models to work as loadable kernel modules.

• This approach would allow different security models to work togethor without modifying the main kernel code.

17

Executables

• Binary Executables:

• ELF (Executables and Linkable Format),

• A.out (Assamby OUT put format),

• COFF (Common Object File Format).

• Java bytecode, scripts and other loadable modules.

18

ELF Format

• Relocatable file (.a)

• Shared object file (.so)

• Executable file (binary)

ELF Header

Program Header Table

Text Segment

Data Segment

BSS Segment

".symtab" section

Section Header Table

Deployment

• Apply a code signing identity and cpk private key.

• Sign all trusted binaries and libraries with codesign toolkit.

• Modify the system startup procedure to load code signing module.

20

Our Works

• Learn details of ELF format and how to insert a signature into a ELF executable or a dynamic library?

• Learn code signing related LSM API or related kernel procedures of other OSs.

• Learn how to access a user-space daemon from kernel module.

• Learn details of deployment.

21

Our Works (cont.)

• How to trust a signature, some factors need to be considered:

• domain,

• vendor,

• product,

• user.

22

Schneier’s Arguments

• Users have no idea how to decide if a particular signer is trusted or not.

• Just because a component is signed doesn't mean that it is safe.

• Just because two component are individually signed does not mean that using them together is safe; lots of accidental harmful interactions can be exploited.

23

Related Projects

• Umbrela

• Bsign (Debian): Signed SHA1 inserted into ELF header.

• DigSig (Ericsson Research Lab): Kernel module for checking BSign signatures.

• Tripwire (Tripwire Inc.):Intrusion detection with file system hashes.

24

References

• http://ask.slashdot.org/article.pl?sid=05/08/31/2045201

• http://users.tkk.fi/~jpkarna/papers/sign.html

• http://sourceforge.net/projects/umbrella

• MSDN: Digital Code Signing Step-by-Step Guide

25

Reference (cont.)

• Microsoft Authenticode Digital ID Instructions － the official guide by VeriSign

• Signing and Checking Code with Authenticode - MSDN

• Signing a XPI - Mozilla

• Code Signing Guide - Apple

26

Linux Security Module Framework

Introduction

• Linux Security Module (LSM) provides Linux kernel with a general purpose framework for access control.

Related Work

Related Work

• POSIX.1e capabilities

• Security Enhanced Linux (SELinux)

• Domain and Type Enforcement (DTE)

• Linux Intrusion Detection System (LIDS)

Design Principles

• truly generic, where using a different security model is merely a matter of loading a different kernel module;

• conceptually simple, minimally invasive, and efficient; and

• able to support the existing POSIX.1e capabilities logic as an optional security module.

User Level Process

User Level Process

Look up inode

Error checks

DAC checks

LSM hook

Complete request

inode

User Space

Kernel Space

Examine contextDoes request pass policy?

Grant or deny

LSM ModulePolicy Engine

access

LSM Hook Architecture

Yes or No

OK with you?

Program Loading

• linux_binprm : Linux binary program

• binprm_security_ops

• include/linux/security.h