network security datasäkerhet/data security eda625 – lect7 · 2015-02-20 - b. smeets lth...

Datasäkerhet/Data securityEDA625 – Lect7

2015-02-20 - B. Smeets LTH Electrical and Information Technology - Datasäkerhet EDA625 1

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

Repetition - lecture 6

Network securityIPsec, VPN, SSLFirewalls


Trusted Platforms and Systems


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

Overview

Intuitive model of trusted platformsPractical applications using trusted platforms to improve securityHardware versus softwareExamples

Java, STIP, .NET, AndroidOSesTrustZone

Description of the two most important trusted platforms: TCG and NGSCB



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)

Attackers may physically tamper with devicesInvasive probingNon-invasive measurementInstall malicious software


Intuitive model

Trusted platform combines best properties of

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

Closed: remote parties can determine what software is running and whether to expect the platform to be well behaved.


Hardware vs Software

Functionlity in Hardware

hard to change high performance possible

Functionlity in Software

Easy to changeDifficult to hold private keys


Trusted Systems in Software

Possible but we have limitations

OK when owner of the device on which software runs is not an attacker (he/she and the device ”work together”/”have the same interests”)

BUT does not work when owner of the device on which software runs is the attacker


Java as trusted execution environment

Example of a pure software solution


Java security models

the need for Java securitythe sandbox (Java 1.0)the concept of trusted code (Java 1.1)fine grained access control (Java 2)


The need for Java security

code mobility can be useful (though not indispensable)may reduce bandwidth requirementsimprove functionality of web services

but downloaded executable content is dangerousthe source may be unknown hence untrustedhostile applets may modify or destroy data in your file systemhostile applets may read private data from your file systemhostile applets may install other hostile code on your system (e.g., virus, back-door, keyboard sniffer, …)hostile applets may try to attack someone else from your system (making you appear as the responsible for the attack)hostile applets may use (up) the resources of your system (DoS)all this may happen without you knowing about it


The sandbox

idea: limit the resources that can be accessed by applets

introduced in Java 1.0local code had unrestricted access to resources downloaded code (applet) was restricted to the sandbox

cannot access the local file systemcannot access system resources,can establish a network connection only with its originating web server

JVM

sandbox

resources

remote code(applets)

local code


The concept of trusted code

idea: applets that originate from a trusted source could be trusted

introduced in Java 1.1applets could be digitally signedunsigned applets and applets signed by an untrusted principal were restricted to the sandboxlocal applications and applets signed by a trusted principal had unrestricted access to resources

JVM

sandbox

resources

remote code(applets)

local code

signed andtrusted

unsigned, orsigned and

untrusted


Fine grained access control

idea: every code (remote or local) has access to the systemresources based on what is defined in a policy file

introduced in Java 2a protection domain is an association of a code source and the permissions grantedthe 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”;};

JVM

resources

local or remote code(signed or unsigned)

class loaders

policyfile


The Java Virtual Machine (JVM)

class loaderinstance

class fileverifier

JIT

primordialclass loader

native methodloader

native methodarea

executionengine

SecurityManager

classarea

heap

operating system

Java code

native code

network

untrusted classes

trusted classes

native methods

local

JVM


The three pillars of Java security

the Security Managerclass loadersthe bytecode verifier


Comparison with ActiveX

ActiveX controls contain native codesecurity is based on the concept of trusted code

ActiveX controls are signedif signer is trusted, then the control is trusted tooonce trusted, the control has full access to resources

not suitable to run untrusted codeno sandbox mechanism


Trusted Computing via HW support

We look at two approaches:

Trusted Computing Group (TCG)

ARM TrustZone


TCG (https://www.trustedcomputinggroup.org/home)

Founded in 1999 by Compaq, HP, IBM, Intel and Microsoft (currently 160 members)

Formally called TCPA (Trusted Computing Platform Alliance)Focus on: PC, Server devicesNew: Mobile TPM

Main use casesSecure bootstrapPlatform attestationProtected storage


TCG – changes to the platform

Added component: Trusted Platform Module (TPM)

Added module (SW or Hardware) for mobile devices: Mobile TPM

Software changes: BIOS + SW StackHW changes: special bus signaling, even new CPU instruction (for DTRM)


TCG Architecture (typically PC or Server)


Trusted Platform Module (TPM v1.2)

Cryptographic operationsHashing: SHA-1, HMACRandom number generatorAsymmetric key generation: RSA (512, 1024, 2048)Asymmetric encryption/ decryption: RSASymmetric encryption/ decryption: DES, 3DES (AES)

PCR Registers ( 16)Tamper resistant storageSmall Gen purpose storage

Asymmetric key generation

Signing and encryption

Random number generator

Hash

Processor Memory

Non-volatile memory 1280) bytes

HMAC

TPM

I/O

PCR registers( 16)


Commercial TMP example - Infineon


The basic TCG idea to trusted system

TBB ( roots of trust)

CRTM code

OS loader code1

Mea

sure

men

t flo

w

2

Exe

cutio

n flo

w

OS code 34

measureexecute


Secure vs authenticated boot

Two methods of bootingSecure Boot: boot can be haltedAuthenticated (or Measured) Boot: just reporting

One uses for thisIntegrity metricPlatform Configuration Register (PCR)


PCRs and measuring during boot

Extending a PCR means:PCR_Extend(n,data): PCR[n+1] SHA1(PCR[n] || data)E.g. when booting

1. Reset PCRs2. PCR_Extend(n,<Bios Code>)3. PCR_Extend(n,<MBR>)4. etc

Platform Configuration Register

Hash Concatenate

extended value present valuemeasured values

TPM

Key Hierarchies “inside” TPM


EK (Endorsement key)

SRK (Storage Root Key)

Take Ownership

AIK (Attestation Id Key) Your key (----)

“make key” and certify that key belongs to SRK

These two will stay always inside TPMIn non-volatile mem.

Question: How to proof that SRK inside TPM ?

Can only be created once.

Keys are stored encrypted*outside TPM

*using parent key=SRK

USER TPM keys

Beside EK, SRK, AIK that have their given role users can create keys of various kinds that allow

Digital signing Protection of user data

En/decryption of keysBinding = en/decryption conditional on PCR values

Remote attestationBasically getting a signed value of PCR values


UEFI hybrid boot


ARM TrustZone

A special mode of operation for the larger ARM coresDivides the SoC into “normal world” and “secure world”

Normal world Secure world

LTH Electrical and Information Technology - Datasäkerhet EDA625 302015-02-20 - B. Smeets

Basic idea

Introduce an NS-bituse this bit to tag secure data throughout system

• Buses• cache• pages

Monitor manages the NS-bitmanages transition in & out of security modeSmall fixed API (so we can better check/verify the code)

LTH Electrical and Information Technology - Datasäkerhet EDA625 312015-02-20 - B. Smeets

ARM TrustZone use

Isolation allows protected processing in secure world by “TA=Trusted Applications”

An ARM TZ system always boots in secure world mode.To make TZ work the platform must implement a secure bootstrap procedure

Today used in many smartphones


Trusted computing in infrastructure

If nodes can be trustedAnd can be checked

We stay in controlin the ”cloud”


See http://www.ericsson.com/res/thecompany/docs/publications/ericsson_review/2014/er-trusted-computing.pdf


Ch 19 GSM, UMTS, LTE Security


Contents

Introduction to mobile telecommunicationsSecond generation systems - GSM securityThird generation systems - UMTS securityFourth generation systems – LTE security

Focus is on security features for network access


Objective

Introduction to Mobile Telecommunications Understand principles of security in GSM and UMTS mobile networksAuthentication, use of (U)SIMCiphering


Cellular Radio Network Architecture

Radio base stations (RBS)are connected to switching centres via fixed or microwave transmission linksform a patchwork of radio cells over a given geographic coverage area

Switching centres are connected to the public networks (fixed telephone network, other GSM networks, Internet, etc.)Mobile terminals

have a relationship with one home network but may be allowed to roam in other visited networks when outside the home network coverage area


Cellular Radio Network Architecture

Homenetwork

Switching and

routing

Other Networks (GSM, fixed, Internet, etc.)

Interconnect

Radio base station

Visited network

Roaming


Location Management

Homenetwork

Switching and

routing


Visited network

HLRVLR

Interconnect

Roaming

Radio base station


First Generation Mobile Phones

First generation analogue phones (NMT, CT) were very insecure:

Cloning: your phone just announced its identity in clear over the radio link

• easy for me to pick up your phone’s identity over the air• easy for me to reprogram my phone with your phone’s identity• Consequence: all my calls are charged to your bill

Eavesdropping• all you have to do is tune a radio receiver until you can hear

someone talking


Digital Mobile Phones

Second generation mobile phones are characterised by the fact that data transmission over the radio link uses digitaltechniques

GSM, CDMA2000

Third generation mobile phones: higher speed, other ways to send signals, better security

UMTS (3G)


GSM Security — The Goals

GSM was intended to be no more vulnerable to cloning or eavesdropping than a fixed phone

it’s a phone not a “secure communications device”!GSM uses integrated cryptographic mechanisms to achieve these goals

just about the first mass market equipment to do thispreviously cryptography had been the domain of the military, security agencies, and businesses worried about industrial espionage, and then banks (but not in mass market equipment)


GSM Security Features

Authenticationnetwork operator can verify the identity of the subscriber making it infeasible to clone someone else’s mobile phone

Confidentialityprotects voice, data and sensitive signalling information (e.g. dialled digits) against eavesdropping on the radio path

Anonymityprotects against someone tracking the location of the user or identifying calls made to or from the user by eavesdropping on the radio path


GSM Security ArchitectureEach mobile subscriber is issued with a unique 128-bit secret key (Ki)

This is stored on a Subscriber Identity Module (SIM) which must be inserted into the mobile phoneThe SIM is a tamper resistant smart card designed to make it infeasible to extract the customer’s Ki

Each subscriber’s Ki is also stored in an Authentication Centre (AuC) associated with the HLR in the home network

GSM security relies on the secrecy of Kiif the Ki could be extracted then the subscription could be cloned and the subscriber’s calls could be eavesdroppedeven the customer should not be able to obtain Ki


GSM Authentication Principles

Network authenticates the SIM to protect against subscriber cloningChallenge-response authentication protocol

SIM demonstrates knowledge of Kiinfeasible for an intruder to obtain information about Ki which could be used to clone the SIM

Encryption key agreementa key (Kc) for radio interface encryption is derived as part of the authentication protocolAuthentication can be performed at call establishment allowing a new Kc to be used for each call


HLR AuC

Visited Access Network VisitedCore Network

Mobile Station (MS)

BSCBTSSIM MESGSN

MSC

HomeNetwork

(2) Authentication

(1) Distribution of authentication data

GSM Authentication

MSC – circuit switched services

SGSN – packet switched services (GPRS)


GSM Authentication: Prerequisites

Authentication Centre (AuC) in home network and security module (SIM) inserted into a mobile phone share

subscriber specific secret key, Kiauthentication algorithm consisting of

• authentication function, A3• key generating function, A8

AuC has a random number generator


GSM Authentication Parameters

Ki = Subscriber authentication key (128 bit)RAND = Authentication challenge (128 bit)(X)RES = A3Ki (RAND)

= (Expected) authentication response (32 bit)Kc = A8Ki (RAND)

= Cipher key (64 bit)

Authentication triplet = {RAND, XRES, Kc} (224 bit)Typically sent in batches to MSC or SGSN


GSM Authentication and Key generation Protocol

MSC orSGSN

HLR/AuCSIM

RAND

RES

{RAND, XRES, Kc}

Authentication DataRequest A3 A8

KiRAND

Kc

RESKc

A8 A3

Ki

RANDXRES

RES = XRES?


GSM Authentication Algorithm

Composed of two algorithms which are often combined

A3 for user authentication A8 for encryption key (Kc) generation

Located in the customer’s SIM and in the home network’s AuCStandardisation of A3/A8 not required and each operator can choose their own

Example: A3/A8 is COMP128


Encryption Mechanism

Encryption is performed by applying a stream cipher called A5 to the GSM TDMA frames, the choice being influenced by

speech codererror propagationdelayhandover


A5

There are 7 possible versions of A5 allowed in GSM. Currently there are two in use called A5/1 and A5/2. A5/2 is a weaker version of A5/1 (export regulations);A5/3 is being introducedA5/4 (uses 128 but key!) standardisation is ready


GSM Security – spying on traffic


Specific GSM Security Problems (1)

Ill advised use of COMP 128 as the A3/A8 algorithm by some operators

vulnerable to collision attack - key can be determined if the responses to about 160,000 chosen challenges are known

• later improved to about 50,000

attack published on Internet in 1998 by Briceno and Goldberg



The GSM cipher A5/1 is becoming vulnerable toexhaustive search on its keyadvances in cryptanalysis

• time-memory trade-off attacks by Biryukov, Shamir and Wagner (2000) and Barkan, Biham and Keller (2003)

• statistical attack by Ekdahl and Johansson (2002)



A5/2 is brokenSame ciphering key for A5/1 and A5/2

Kc can be found by forcing (false base station) to operate A5/2. A5/2 can be cryptanalyzedA5/1 encrypted transmission can be listened into because Kc is still use (there is seldom a change of Kc) but is now know Hence affects security of use of A5/1 as well


Specific GSM Security Problems (4) False Base Stations

Used as IMSI Catcherforce mobile to reveal it’s IMSI in clear

Used to intercept mobile-originated callsencryption controlled by network and user generally unaware if it is not onfalse base station masquerades as network with encryption switched offcalls relayed to called partycipher indicator helps guard against attack

Risk of radio channel hijack, but only if encryption is not used


Lessons Learnt from GSM Experience

Security must operate without user assistance, but the user should know it is happeningBase user security on smart cards Possibility of an attack is a problem even if attack is unlikely

Don’t relegate lawful interception to an afterthought - especially as one considers end-to-end securityDevelop open international standards Use published algorithms, or publish any specially developed algorithms


Third Generation Mobile Phones – The UMTS Standard


Third Generation Mobile Phones – The UMTS Standard

Third generation (3G) mobile phones are characterised by higher rates of data transmission and a richer range of servicesUniversal Mobile Telecommunications System (UMTS) is one of the new 3G systems

UMTS introduces a new radio technology into the access network

• Wideband Code Division Multiple Access (W-CDMA)

An important characteristic of UMTS is thatthe new radio access network is connected to an evolution of the GSM core network


Principles of UMTS Security

Build on the security of GSMadopt the security features from GSM that have proved to be needed and that are robusttry to ensure compatibility with GSM to ease inter-working and handover

Correct the problems with GSM by addressing security weaknesses Add new security features

to secure new services offered by UMTSto address changes in network architecture


UMTS Network Architecture

Homenetwork

Switching and routing

Visited core network (GSM-based)

HLR/AuC

RNC

RNC

USIM

New radio access network

VLR



New Security Features for UMTS

Mutual authentication and key agreementextension of user authentication mechanismprovides enhanced protection against false base station attacks by allowing the mobile to authenticate the network

Integrity protection of critical signalling between mobile and radio network controller

provides enhanced protection against false base stationattacks by allowing the mobile to check the authenticity of certain signalling messages extends the influence of user authentication when encryption is not applied by allowing the network to check the authenticity of certain signalling messages


The 3GPP security algorithms

f0: random generator: AuC, SIM (?) f1 network authentication algorithm: HE, SIMf2 user authentication functionf3 cipher derivation functionf4 integrity key derivation functionf5 anonymity key derivation functionf6,f7 user identity en/decryption function: USIM, AuCf8 UMTS ciphering algorithm: UE, RNCf9 UMTS integrity algorithm: UE, RNC


UMTS Authentication Parameters

K = Subscriber authentication key (128 bit)RAND = User authentication challenge (128 bit)SQN = Sequence number (48 bit)AMF = Authentication management field (16 bit)MAC = f1K (SQN||RAND||AMF) =

Message Authentication Code (64 bit)(X)RES = f2K (RAND)

= (Expected) user response (32-128 bit)CK = f3K (RAND) = Cipher key (128 bit)IK = f4K (RAND) = Integrity key (128 bit)AK = f5K (RAND) = Anonymity key (48 bit)AUTN = SQN AK|| AMF||MAC = Authentication Token (128 bit)

Authentication quintet = {RAND, XRES, CK, IK, AUTN} (544-640 bit)• typically sent in batches to MSC or SGSN


UMTS Authentication

MSC or SGSN HLR/AuCUSIM

RAND,SQN AK||AMF||MAC

RES

{RAND, XRES, CK, IK,SQN AK||AMF||MAC}

Authentication Data Request

XRES, CK, IK, AK, MAC

RAND

K f1-f5

SQN

Verify MAC using f1Decrypt SQN using f5Check SQN freshness

RES, CK, IK

RAND

f2-f4K

AMF

RES = XRES?


LTE Security

GOALS:Main conceptsMotivationDifferences with UMTS

LTE and EPS

Long Term Evolution (LTE) is the mobile radio technology following after that of UMTS. The main motives to start the work on LTE were (again) increased capacity and throughput, and decreased latency. In parallel work was started on the Evolved Packet System (EPS) aiming for a simpler core network, and to integrate non-3GPP access technologies.

For simplicity we only speak about LTE security



LTE Security architecture basics and trust assumptions

Cor

e N

W

eNB

S-GWMME

eNB

HSSPDN

RA

N

Non trusted locationtrusted environment

Trusted environment

IPseceNB BSS for LTE

Internet

Mitigating the risk of false eNBs during handover

When handover occurs between two eNBs, the source eNB needs to transfer security parameters to the target eNBThreats:

Source eNB is compromised• Forward security: recover from compromised source eNB

Target eNB is compromised• Backward security: keep previous traffic secure in case of

compromised target eNB



LTE Key hierarchy

K_eNB-RRC-encK_eNB-RRC-intK_eNB-UP-enc

K_eNBK_NAS-int K_NAS-enc

K_ASME

CK IK

K

USIM/AUC

UE/HSS

UE/MME

UE/eNBUE/MME

key derivationfunctions

Access from foreign networks

GSM SIM cards not accepted anymorePrinciple: For non-3GPP access to EPS uses the USIM card.

EAP AKA-based mutual authentication is always performed between a UE (USIM) and the authentication, authorization and accounting (AAA) server.

Special:UMTSCDMA2000/High-Rate Packet Data (HRPD)


Literature

3GPP System Architecture Evolution (SAE), Security architecture, (Release 11), 3GPP TS 33.104UMTS Security, Valtteri Niemi and KaisaNyberg, Wiley, 2003LTE Security, D. Forsberg, et al, Wiley, 2010Security in the Evolved Packet System, R. Blom, et al. Ericsson Review, Oct 2010,http://www.ericsson.com/res/thecompany/docs/publications/ericsson_review/2010/security_eps.pdf

2015-02-20 - B. Smeets LTH Electrical and Information Technology - Datasäkerhet EDA625 73 2015-02-20 - B. Smeets LTH Electrical and Information Technology - Datasäkerhet EDA625 74

Standards

3GPP standards, http://www.3gpp.org/ftp/specs/latest

TS 43.020 – for GSM security features TS 33.102 – for UMTS security featuresTS 33.401– for LTE security features

Mobile Internet

Allows at IP network level seamless interworking between mobile network and wlan network

Not widely deployed but is in use, eg. AT&T in the US to off-load mobile network where there is WLAN access


WLAN IEEE802.11 Architecture


IEEE 802.11

WEP vs. WPA vs. WPA2


WEP WPA WPA2

Encryption RC4 RC4 AES

Key rotation None Dynamic session keys

Dynamic session keys

Key distribution Manually typed into each device

Automatic distribution available

Automatic distribution available

Authentication Uses WEP key as AuthC

Can use 802.1x & EAP

Can use 802.1x & EAP

insecure avoid

Main deployment modes

Enterprise modew/RADIUS for authC

Pre-Shared Key (PSK) mode (Aka Home or SOHO mode)

User enters master key on each computer


network security datasäkerhet/data security eda625 – lect7 · 2015-02-20 - b. smeets lth...

Documents