The Use of System Security Description Method in Security Design Assessment: A Case Study

Tsukasa Maeda, Masahito KuriharaGraduate School of Information Science and Technologies

Hokkaido University

Difficulty in developing secure systems HARD TO FIND

It is difficult to discover threats and vulnerabilities hidden behind the complex structure of a system Many system components

HARD TO DESCRIBE There is the difficulty of communications between various stakeholders of a system.

Hard to express security properties Security expertise needed to analyze system security

Digital Right Management System

ContentDistribution

LicenseRequest

License

CP

UD

LS

　　　

　　　　　　

•Contents Providers (CPs): create content and distribute copies of them to the public.•User devices (UDs): obtain content, purchase the licenses (right to use), and use or otherwise access the content. Mobile phones, game devices, and media players are examples of UDs.•License server (LS): sells licenses to users who use UDs.

Solution: New Description Method Easy to depict weakness of system

Weak system components are replaceable Easy to express security properties

Description with abstract security services Confidentiality, authenticity

Description with single type of simple object Entity

Description Method: Building Block

system ： = {e1, e2, ..., ek} ; e ｊ　 is an entity entity ： =(Identity, Secret, Credentials, Trust , Adjacen

cy)

Execution　 Entity

Execution　 Entity

ExecutionEntity

Link Entity Link Entity

Type of Entity• An execution entity is an object that performs information processing whil

e interacting with other execution entities.• A link entity is a virtual entity that models a communication channel

established by a cryptographic protocol such as SSL/TLS and Kerberos between two interacting execution entities.

Entity

Identity

Secret

Trust

Credentials

Adjacency

Name to identify this entity

Secret information for being authenticatedEx. passcode, private key, symmetric key

Processes to generate information beinggiven to entities authenticating this entityEx. hash of passcode, signature, encrypted dataProcesses to receive information andverify it to authenticate other entities

Entities adjacent to this entity

Secret has strength.Ex. RSA 1024bits key 128bits symmetric key⇒ AES 128bits key = 128bits symmetric key password ≒ 60 bits entropy *1

no secret = 0 (⊥)

*1:NIST SP800-63-1

Configuring A Link Entity

A BLink X

A

Secret

Trust for B

Credentials to B

X

A,B

B

Secret

Trust for A

Credentials to A

E(m)k

k

E(m)k

Trust for BE(m)k

Trust for AE(m)k

Copy of Trust for BCopy of Trust for A

X X

The Entity Combination Rule

A

Secret

Credentials to B

Trust for B

B

B

Secret

Credentials to A

Trust for A

A

Two entities adjoined each other can be combined to form a single entity if

1. identities should be validated by each other on every data transfer,

2. Both entities have comparable strength strong enough to satisfy security requirements of the system, and

3. Credential elements to be given to each other for authentication have real-time factors in their input.

Secret Secret

Credentials to B Credentials to A

Trust for ATrust for B

A,B

Secret A,B

SSLSSL

Example1: Web Access

A B C

Step 1. Identifying execution entities in the system and diagramming them in a chart.

A: UserB: BrowserC: Web Server

Step 2. Determining the SECRET, CREDENTIAL and TRUST elements of the execution entities

Trust

Identity

Credential

Adj

Secret

Example: Web AccessStep 3. Specifying the link entities

CA B

PW ⊥ Kpri

PW ⊥ (Kpri,r)

B.A( )⊥B.C(Kpub,r)

A.B( )⊥A.C( )⊥

C.A(PW)C.B( )⊥

X D

Ks,Kc⊥

E(m)Ks, E(m)Kc⊥

Step 4. Configuring the link entities

X X,D DB,C

A,B

D.C(Kpub,r)D.B( ) ⊥

X.B( )⊥X.A( )⊥

C.A(PW)C.B( )⊥C.D(Kc)

D.C(Kpub,r)D.B( ) ⊥

(Kpri,r)

B.A( )⊥B.C(Kpub,r)B.D(Ks)

A.B( )⊥A.C( )⊥

X.B( )⊥X.A( )⊥

Step 5. Applying the combination rule;

E

Kpri,Ks,Kc

E.A(PW)E.B( )⊥

B

(Kpri,r), E(m)Ks, E(m)Kc

Threats: Replaceable entities•Weak secrets•Not kept being validated by any non-replaceable entities•Credential elements are replicable

Risks: The possibility of replacing entities•Measuring possibilities and taking suitable actions

A Case Study: Digital Right Management System

ContentDistribution

LicenseRequest

License

CP

UD

LS

　　　

　　　　　　

•Contents Providers (CPs): create content and distribute copies of them to the public.•User devices (UDs): obtain content, purchase the licenses (right to use), and use or otherwise access the content. Mobile phones, game devices, and media players are examples of UDs.•License server (LS): sells licenses to users who use UDs.

Content package := S(E(CEK)KLSP)KCPS || E(m)CEK

License Request := S(E(CEK)KLSP)KCPS (Sending the header)License := CEK (Receiving decrypted CEK)

Modeling Contents Distribution

UD CP

UID KCPS

UD.LS(UID,r) CP.LS(KLSP)

ContentPackage

LS

KLSS,UID

LS.UD(UID,r)LS.CP(KCPP)

Secret

Trust

U CP

KLSS KCPSCEK

M.CP(KCPP)M.U(KLSP)

M

Credential:(KCPS) =

U.CP(KCPP) 　U.M(CEK,m) 　

CP.M(CEK,m)CP.LS(KLSP)

CPSLSP KKCEKES

Content package := S(E(CEK)KLSP)KCPS || E(m)CEK

Combining All Entities

U

KLSS

U.V(CEK,m)

CEK， KCPS

V.U(KLSP)= V.U(CEK)

V

Credential:(KLSS) =CEK

All entities are combined and form a single entity.

A Secure System

Challenge

Can we make trust management dynamic? Transitional Trust Dynamic Trust Allocation

Thank you.

Description Method:Security Objectives Confidentiality of data and system information Integrity of system and data Availability of systems and data for intended use

only

1. Trusted entities are believed to meet these objectives

2. The combination rule preserves them.

Example2:OTPEA B

PW ⊥ Kpri,Ks,Kc

B.A( )⊥A.C( )⊥

B.A( )⊥B.E(Kpub,r)

B.E(Ks)

BX,EX

(PW,t) ⊥ (Kpri,r), E(m)Ks, E(m)Kc

X

⊥

⊥

X.B( )⊥X.A( )⊥

A,B

E.A((PW,t))E.B( )⊥

Threats: Relaceable entities•Not kept being validated by any non-replaceable entities•Weak secrets•Credential elements are replicable