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 Content Distribution License Request 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 ： = {e 1, e 2,..., e k } ; e ｊ is an entity entity ： =(Identity, Secret, Credentials, Trust, Adjacency) Execution Entity Execution Entity Link Entity 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.

Entity Identity Secret Trust Credentials Adjacency Name to identify this entity 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 Processes to receive information and verify 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 SP

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

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 Credentials to B Credentials to A Trust for ATrust for B A,B Secret A,B

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

Step 2. Determining the SECRET, CREDENTIAL and TRUST elements of the execution entities Trust Identity Credential Adj Secret Example: Web Access Step 3. Specifying the link entities CAB PW ⊥ K pri PW ⊥  (K pri,r)  B.A ( ⊥ )  B.C (K pub,r)  A.B ( ⊥ )  A.C ( ⊥ )  C.A (PW)  C.B ( ⊥ ) XD Ks,KcKs,Kc ⊥ E(m) Ks, E(m) Kc ⊥ Step 4. Configuring the link entities XX,DDB,C A,B  D.C (K pub,r)  D.B ( ⊥ )  X.B ( ⊥ )  X.A ( ⊥ )  C.A (PW)  C.B ( ⊥ )  C.D (K c )  D.C (K pub,r)  D.B ( ⊥ )  (K pri,r)  B.A ( ⊥ )  B.C (K pub,r)  B.D (K s )  A.B ( ⊥ )  A.C ( ⊥ )  X.B ( ⊥ )  X.A ( ⊥ ) Step 5. Applying the combination rule; E K pri,K s,K c  E.A (PW)  E.B ( ⊥ ) B  (K pri,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 Content Distribution License Request 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 UDCP UIDK CPS  UD.LS (UID,r)  CP.LS (K LSP ) Content Package LS K LSS,UID  LS.UD (UID,r)  LS.CP (K CPP ) Secret Trust UCP K LSS K CPS CEK  M.CP (K CPP )  M.U (K LSP ) M Credential:  (K CPS ) =  U.CP (K CPP )  U.M (CEK,m)  CP.M (CEK,m)  CP.LS (K LSP ) Content package := S(E(CEK)KLSP)KCPS || E(m)CEK

Combining All Entities U K LSS  U.V (CEK,m) CEK ， K CPS  V.U (K LSP )=  V.U (CEK) V Credential:  (K LSS ) =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:OTP EAB PW ⊥ K pri,K s,K c  B.A ( ⊥ )  A.C ( ⊥ )  B.A ( ⊥ )  B.E (K pub,r)  B.E (K s ) BX,EX  (PW,t) ⊥  (K pri,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