Security Validation on Open Source Projects

Costel Maxim Security Validation Engineer, Intel

1

Reliability/stability/scalability are critical Correctness of design and implementation The software is critical to the users control of the business. The software establishes or enables a common computing and communications infrastructure

2

The following discriminators push towards open source

Well defined goals Do not skip the crucial details Motivated and organized people Resources needed to sustain the project

3

Things need to keep the wheels moving

4

Security in open source

December 2004, Wired Magazine

2030 bugs in proprietary software

(Carnegie Mellon University Cylab)

0.17 bugs in the Linux 2.6 kernel

(Stanford University/Cover)

January 2008, Department of

Homeland Security

One bug in proprietary software

0.127 bugs in the Linux 2.6 kernel

0.14 bugs in Apache

0.041 bugs in PostgreSQL

Zero bugs in gcc

Secured infrastructure Free source code for everybody Defined work flow Design and influence

5

Security Requirements

6

Intel met Android

Security model

Sandboxed applications direct interaction between

applications is prevented

Each application requires a specific rules set

Encryption

Android Security Issues

7

Android* Security

Features validation Static code analysis Secure boot DRM Whole disk encryption Common Vulnerabilities and Exposures

8

Security Validation activities done for Android*

Linux based

HTML5, CSS3, JavaScript

Tizen* Web API

AppUP

SDK, Simulator, Emulator

Smartphone, Tablet, Netbook, Smart TV, IVI

Open source community contribution

9

Tizen*

SMACK is the Simplified Mandatory Access Control Kernel.

Applications are running in a sandbox - isolated

Controlled access to resources smack label

Minimum privileges

Standard applications run with the same ID and non root access

10

Tizen security model

11

Tizen Manifest example

A new label for labelling camera statistic data

A new label for labelling camera data that contains information about timings

A new label for labelling camera public data

12

Tizen Threat Model

13

Security Development Lifecycle Process

The purpose of your engineering project is to produce a product; the Security Design Lifecycle

(SDL) process enables the project team to produce a secure project.

14

Security Development Lifecycle Process

DO NOT develop or implement your own cryptographic protocols or algorithms without Security Architecture Forum (SAFE) review.

When using hashing features, select only the SHA-2 algorithm. Source code available at RFC6234

When using HMAC, use only FIPS PUB-198 approved HMAC algorithms.

When implementing a PRNG or DRBG product, conform to NIST SP800-90.

Use AES algorithm for symmetric encryption.

Do not use Electronic Code Book (ECB) mode on data sizes of more than a single block, when using AES.

Use RSA for digital signatures

Use RSA or Diffie-Hellman for key exchange.

When implementing RSA functions, conform to ANSI X9.31 and PKCS #1 specification.

Cryptographic keys shall be used for only one purpose.

Follow protection requirements for keys during distribution and storage.

Follow key backup and recovery requirements.

When selecting a cryptographic provider, use hardware based crypto when available.

All traces of cryptographic keys shall be destroyed as soon as the key is no longer required.

When architecting a solution, a key replacement strategy is required.

Debug/Test keys should be different than the production keys.

Ensure cryptographic keys or secret data are not extractable via scan or debug channels.

15

Requirments: Crypto and Key Management

Architect secure update mechanisms.

Security components should be designed to fail intelligently.

When designing complex products, use identification, authentication,

authorization and secure communication when necessary.

Minimize the attack surface by removing unnecessary components,

APIs, entry point, privilege levels, etc.

Limit the number of applications that require administrator or root

privileges.

16

Requirments: Secure Architecture

Follow secure review guidelines during review of the high risk code.

Follow industry secure coding guidelines

Release build code should be free of backdoors.

Avoid embedding secrets in the code

Use the most restrictive data types for parameters.

All debug and observability capabilities should be removed, disabled or secured prior to shipment.

Initialize all variables in your code.

All code that consumes memory should properly free itself at all exit points.

To avoid race conditions use thread safe libraries, avoid shared resources between threads and use mutex if available

For all code written in C / C++ / Java use the Klocwork Static Analysis suite or comparable tool.

17

Requirments: Software Security

18

19

Thank you

Bad Use of Encryption!