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

The Use of System Security Description Method in Security Design Assessment: A Case Study Tsukasa Maeda, Masahito Kurihara Graduate 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 • 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. LS License Request License CP UD Content Distribution

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

ExecutionEntity Link Entity ExecutionEntity Link Entity Execution Entity Description Method: Building Block • system ：= {e1, e2, ..., ek} ; eｊ　 is an entity • entity ：=(Identity, Secret, Credentials, Trust , Adjacency) • Type of Entity • An execution entity is an object that performs information processing while 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.

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 Entity Identity Name to identify this entity Secret Secret information for being authenticated Ex. passcode, private key, symmetric key Processes to generate information being given to entities authenticating this entity Ex. hash of passcode, signature, encrypted data Credentials Trust Processes to receive information and verify it to authenticate other entities Adjacency Entities adjacent to this entity

k E(m)k Trust for B E(m)k Copy of Trust for B Copy of Trust for A Trust for A E(m)k X X Configuring A Link Entity A B Link X E(m)k A X B Secret Secret Credentials to B Credentials to A Trust for B Trust for A A,B

A,B Secret A,B Secret Secret Credentials to B Credentials to A Trust for B Trust for A The Entity Combination Rule • Two entities adjoined each other can be combined to form a single entity if • identities should be validated by each other on every data transfer, • Both entities have comparable strength strong enough to satisfy security requirements of the system, and • Credential elements to be given to each other for authentication have real-time factors in their input. A B Secret Secret Credentials to B Credentials to A Trust for B Trust for A B A

A B C SSL Example1: Web Access A: User B: Browser C: Web Server Step 1. Identifying execution entities in the system and diagramming them in a chart.

X D E Kpri,Ks,Kc f(Kpri,r) ⊥ f(Kpri,r), E(m)Ks,E(m)Kc E(m)Ks,E(m)Kc gA.B(⊥) gA.C(⊥) gA.B(⊥) gA.C(⊥) gX.B(⊥) gX.A(⊥) gX.B(⊥) gX.A(⊥) gB.A(⊥) gB.C(Kpub,r) gB.A(⊥) gB.C(Kpub,r) gB.D(Ks) gD.C(Kpub,r) gD.B(⊥) gE.A(PW) gE.B(⊥) gD.C(Kpub,r) gD.B(⊥) gC.A(PW) gC.B(⊥) gC.D(Kc) gC.A(PW) gC.B(⊥) ⊥ Ks,Kc X A,B X,D B B,C D PW ⊥ f(Kpri,r) PW ⊥ Kpri Example: Web Access Step 2. Determining the SECRET, CREDENTIAL and TRUST elements of the execution entities Step 4. Configuring the link entities Step 3. Specifying the link entities Step 5. Applying the combination rule; Identity A B C Secret Credential Trust Adj • 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 • 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. LS License Request License CP UD Content Distribution 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 LS UD CP Secret KLSS,UID UID KCPS Content Package gLS.UD(UID,r) gLS.CP(KCPP) gUD.LS(UID,r) gCP.LS(KLSP) Trust U M CP KLSS CEK KCPS Credential:f(KCPS) = gU.CP(KCPP) gU.M(CEK,m) gM.CP(KCPP) gM.U(KLSP) gCP.M(CEK,m) gCP.LS(KLSP) Content package := S(E(CEK)KLSP)KCPS || E(m)CEK

A Secure System Combining All Entities U V KLSS CEK，KCPS Credential:f(KLSS) =CEK gU.V(CEK,m) gV.U(KLSP)= gV.U(CEK) All entities are combined and form a single entity.

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 • Trusted entities are believed to meet these objectives • The combination rule preserves them.

Example2:OTP A X B E PW ⊥ ⊥ Kpri,Ks,Kc f(PW,t) ⊥ ⊥ f(Kpri,r), E(m)Ks,E(m)Kc gB.A(⊥) gA.C(⊥) gX.B(⊥) gX.A(⊥) gB.A(⊥) gB.E(Kpub,r) gB.E(Ks) gE.A(f(PW,t)) gE.B(⊥) X A,B X,E B • Threats: Relaceable entities • Not kept being validated by any non-replaceable entities • Weak secrets • Credential elements are replicable

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