security-by-contract for applications’ evolution in multi
TRANSCRIPT
![Page 1: Security-by-Contract for Applications’ Evolution in Multi](https://reader031.vdocuments.site/reader031/viewer/2022020706/61fc9e579d50e757a521b85c/html5/thumbnails/1.jpg)
DTU InformaticsDepartment of Informatics and Mathematical Modelling
02234 - Autumn 2010
Security-by-Contract for Applications’ Evolution in Multi-Application Smart Cards
Nicola [email protected]
http://www2.imm.dtu.dk/~ndraEmbedded Systems Engineering (ESE) Section
DTU InformaticsTechnical University of Denmark (DTU)
![Page 2: Security-by-Contract for Applications’ Evolution in Multi](https://reader031.vdocuments.site/reader031/viewer/2022020706/61fc9e579d50e757a521b85c/html5/thumbnails/2.jpg)
DTU InformaticsDepartment of Informatics and Mathematical Modelling
02234 - Autumn 2010
Talk Outline
‣ Domain: multi-application smart cards
‣ Problem: supporting applications’ evolution
‣ Approach: Security-by-Contract (key idea)
2
Smart Card
![Page 3: Security-by-Contract for Applications’ Evolution in Multi](https://reader031.vdocuments.site/reader031/viewer/2022020706/61fc9e579d50e757a521b85c/html5/thumbnails/3.jpg)
DTU InformaticsDepartment of Informatics and Mathematical Modelling
02234 - Autumn 2010
Multi-Application Smart Cards
3
Smart Card
• Multi-application smart cards: several applications run on the same card
• Applications (Web clients and servers) are owned and asynchronously controlled by different stakeholders
• Applications can dynamically be loaded, changed and removed during the active life of the card
![Page 4: Security-by-Contract for Applications’ Evolution in Multi](https://reader031.vdocuments.site/reader031/viewer/2022020706/61fc9e579d50e757a521b85c/html5/thumbnails/4.jpg)
DTU InformaticsDepartment of Informatics and Mathematical Modelling
02234 - Autumn 2010
JAVA CARD = JRE + GLOBALPLATFORM
• GlobalPlatform = Middleware (with Open Specifications)
‣ Lots of smart card deployed with those specifications
• Java Card = GlobalPlatform + Java Runtime Environment
‣ Support loading and unloading of many applications on the fly and asynchronously
‣ Allow interactions among applications on the card (through Shareable Interface inherited services)
4
![Page 5: Security-by-Contract for Applications’ Evolution in Multi](https://reader031.vdocuments.site/reader031/viewer/2022020706/61fc9e579d50e757a521b85c/html5/thumbnails/5.jpg)
DTU InformaticsDepartment of Informatics and Mathematical Modelling
02234 - Autumn 2010
JAVA CARD = JRE + GLOBALPLATFORM
• GlobalPlatform = Middleware (with Open Specifications)
‣ Lots of smart card deployed with those specifications
• Java Card = GlobalPlatform + Java Runtime Environment
‣ Support loading and unloading of many applications on the fly and asynchronously
‣ Allow interactions among applications on the card (through Shareable Interface inherited services)
• Still/Yet/But…
‣ There is NO fielded open multi-application smart card
4
![Page 6: Security-by-Contract for Applications’ Evolution in Multi](https://reader031.vdocuments.site/reader031/viewer/2022020706/61fc9e579d50e757a521b85c/html5/thumbnails/6.jpg)
DTU InformaticsDepartment of Informatics and Mathematical Modelling
02234 - Autumn 2010
The Card Platform
5
Applications run in dedicated security domains. The name is evocative of a separate space (such as in a virtual machine) but in reality a domain just supports some security services...
![Page 7: Security-by-Contract for Applications’ Evolution in Multi](https://reader031.vdocuments.site/reader031/viewer/2022020706/61fc9e579d50e757a521b85c/html5/thumbnails/7.jpg)
DTU InformaticsDepartment of Informatics and Mathematical Modelling
02234 - Autumn 2010
Security Domains??!!
From GP specification:
Security Domains act as the on-card representatives of off-card authorities.
Security Domains support security services such as key handling, encryption, decryption, digital signature generation and verification for their providers' (Card Issuer, Application Provider or Controlling Authority) applications.
Each Security Domain is established on behalf of a Card Issuer, an Application Provider or a Controlling Authority when these off-card entities require the use of keys that are completely isolated from each other.
6
![Page 8: Security-by-Contract for Applications’ Evolution in Multi](https://reader031.vdocuments.site/reader031/viewer/2022020706/61fc9e579d50e757a521b85c/html5/thumbnails/8.jpg)
DTU InformaticsDepartment of Informatics and Mathematical Modelling
02234 - Autumn 2010
Problem: Control of Interactions Among Applications
• Policy for security domains:
‣ Only Bank can be called by Transport
‣ Transport will only call Bank
• Policy for applications:
‣ EMV@Bank will only be called by ePurse@Bank
‣ ePurse@Bank can only be called by jTicket@Transport and will only call EMV@Bank
‣ jTicket@Transport will only call ePurse@Bank
• New application Points@Loyalty arrives on the platform. Desired behavior:
‣ Points@Loyalty will only call ePurse@Bank
‣ And here we have a problem!
7
![Page 9: Security-by-Contract for Applications’ Evolution in Multi](https://reader031.vdocuments.site/reader031/viewer/2022020706/61fc9e579d50e757a521b85c/html5/thumbnails/9.jpg)
DTU InformaticsDepartment of Informatics and Mathematical Modelling
02234 - Autumn 2010
Ok... But... Wait a Minute... GP??!!
• GP does not solve the problems of illegal information exchange even for the applications from different security domains
• All inter-application interactions are pushed to lower levels ==> runtime environment or even hardware
• Example: in Java Card, the control of the communications between the applications and the applications and the platform rests on the JRE!!
8
![Page 10: Security-by-Contract for Applications’ Evolution in Multi](https://reader031.vdocuments.site/reader031/viewer/2022020706/61fc9e579d50e757a521b85c/html5/thumbnails/10.jpg)
DTU InformaticsDepartment of Informatics and Mathematical Modelling
02234 - Autumn 2010
Yes... Ok... But... Wait a Minute... JRE Firewall??!!
‣ The internal operations of an applet have no effect on other applets embedded on the card!!
• JRE has a firewall security mechanism that isolates each applet from the other applets within of its own context!!
9
![Page 11: Security-by-Contract for Applications’ Evolution in Multi](https://reader031.vdocuments.site/reader031/viewer/2022020706/61fc9e579d50e757a521b85c/html5/thumbnails/11.jpg)
DTU InformaticsDepartment of Informatics and Mathematical Modelling
02234 - Autumn 2010
Yes... Ok... But... Wait a Minute... JRE Firewall??!!
‣ Still, applications can interact in this environment by explicitly implementing shareable methods callable via an API!! (Application service in Java Card 3.0 specification or Global Services in the GP specification)
‣ The internal operations of an applet have no effect on other applets embedded on the card!!
• JRE has a firewall security mechanism that isolates each applet from the other applets within of its own context!!
• If application A knows shareable interface of application B, then it may use it for its own purposes, and there is no means for B or B security domain owner to prevent it, unless special controls are hacked into the Java firewall
‣ However this completely prevents the asynchronous download or update of different applications!!
9
![Page 12: Security-by-Contract for Applications’ Evolution in Multi](https://reader031.vdocuments.site/reader031/viewer/2022020706/61fc9e579d50e757a521b85c/html5/thumbnails/12.jpg)
DTU InformaticsDepartment of Informatics and Mathematical Modelling
02234 - Autumn 2010
What About the Available Business Solutions?
• There are business solutions for multi-application smart cards on top of GP and Java Card from Venyon Oy, Gemalto and companies alike developed for banking, transport and mobile operators
• But typical solution from such companies is only responsible for
‣ handling loading of card customer applications
‣ security domain key handling
‣ management and removal of applications
• Such a solution is only an improvement of GP, but it is not dealing with:
‣ certification of new applications on the card
‣ checks of compliance with new applications to the initial card security policy
‣ checks if the removal of some application is even possible and will not break the work of others remaining on the card
10
![Page 13: Security-by-Contract for Applications’ Evolution in Multi](https://reader031.vdocuments.site/reader031/viewer/2022020706/61fc9e579d50e757a521b85c/html5/thumbnails/13.jpg)
DTU InformaticsDepartment of Informatics and Mathematical Modelling
02234 - Autumn 2010
Back to “The” Problem
• What remains out of reach is a secure way to deploy new applications on the multi-application smart card once it is in the field
• A costly manual review is necessary!
• What owners of different trust domains wants: to make sure their applications cannot be accessed by new applications added after theirs!
• What smart card developers have to prove: all the changes that are possible to apply to the card are security-free!!
‣ In this way their formal proof of compliance with Common Criteria is still valid after that changes and they do not need to obtain a new certificate...
11
![Page 14: Security-by-Contract for Applications’ Evolution in Multi](https://reader031.vdocuments.site/reader031/viewer/2022020706/61fc9e579d50e757a521b85c/html5/thumbnails/14.jpg)
DTU InformaticsDepartment of Informatics and Mathematical Modelling
02234 - Autumn 2010
“The” (Security) Requirement of Smart Cards
• Java Card applications must be Common Criteria certified to respect a certain policy of each stakeholder
‣ Pre-issuance certification when the card is prepared
‣ All later changes must show they meet the same policy
12
![Page 15: Security-by-Contract for Applications’ Evolution in Multi](https://reader031.vdocuments.site/reader031/viewer/2022020706/61fc9e579d50e757a521b85c/html5/thumbnails/15.jpg)
DTU InformaticsDepartment of Informatics and Mathematical Modelling
02234 - Autumn 2010
“The” (Security) Requirement of Smart Cards
• Java Card applications must be Common Criteria certified to respect a certain policy of each stakeholder
‣ Pre-issuance certification when the card is prepared
‣ All later changes must show they meet the same policy
• Solution 1 – Theory
‣ Certify the application for all possible changes of itself AND its fellow applications
12
![Page 16: Security-by-Contract for Applications’ Evolution in Multi](https://reader031.vdocuments.site/reader031/viewer/2022020706/61fc9e579d50e757a521b85c/html5/thumbnails/16.jpg)
DTU InformaticsDepartment of Informatics and Mathematical Modelling
02234 - Autumn 2010
“The” (Security) Requirement of Smart Cards
• Java Card applications must be Common Criteria certified to respect a certain policy of each stakeholder
‣ Pre-issuance certification when the card is prepared
‣ All later changes must show they meet the same policy
• Solution 1 – Theory
‣ Certify the application for all possible changes of itself AND its fellow applications
• Solution 2 – Another Theory
‣ Run-time monitor new applications to prevent their interactions with old applications if it’s forbidden
12
![Page 17: Security-by-Contract for Applications’ Evolution in Multi](https://reader031.vdocuments.site/reader031/viewer/2022020706/61fc9e579d50e757a521b85c/html5/thumbnails/17.jpg)
DTU InformaticsDepartment of Informatics and Mathematical Modelling
02234 - Autumn 2010
“The” (Security) Requirement of Smart Cards
• Java Card applications must be Common Criteria certified to respect a certain policy of each stakeholder
‣ Pre-issuance certification when the card is prepared
‣ All later changes must show they meet the same policy
• Solution 1 – Theory
‣ Certify the application for all possible changes of itself AND its fellow applications
• Solution 2 – Another Theory
‣ Run-time monitor new applications to prevent their interactions with old applications if it’s forbidden
• Solution 3 – Practice
‣ Don’t allow post-issuance evolution…
12
![Page 18: Security-by-Contract for Applications’ Evolution in Multi](https://reader031.vdocuments.site/reader031/viewer/2022020706/61fc9e579d50e757a521b85c/html5/thumbnails/18.jpg)
DTU InformaticsDepartment of Informatics and Mathematical Modelling
02234 - Autumn 2010
What We Want: Supporting Applications’ Evolution
• Download new applications, delete old applications, update applications, update/change policy of the smart card
• Applications are signed and come with their own “policy”, describing their security behavior
• New applications should
✓not interact with some “old” applications (if that is not wanted)
✓interact with other “old” applications (if that is wanted)
13
![Page 19: Security-by-Contract for Applications’ Evolution in Multi](https://reader031.vdocuments.site/reader031/viewer/2022020706/61fc9e579d50e757a521b85c/html5/thumbnails/19.jpg)
DTU InformaticsDepartment of Informatics and Mathematical Modelling
02234 - Autumn 2010
What We Want: Supporting Applications’ Evolution
• Download new applications, delete old applications, update applications, update/change policy of the smart card
• Applications are signed and come with their own “policy”, describing their security behavior
• New applications should
✓not interact with some “old” applications (if that is not wanted)
✓interact with other “old” applications (if that is wanted)
13
We want to support applications’ evolution in multi-application smart cards
![Page 20: Security-by-Contract for Applications’ Evolution in Multi](https://reader031.vdocuments.site/reader031/viewer/2022020706/61fc9e579d50e757a521b85c/html5/thumbnails/20.jpg)
DTU InformaticsDepartment of Informatics and Mathematical Modelling
02234 - Autumn 2010
Possible Interactions
• Policy for security domains:- SD1 cannot call SD2- SD3 only can be called after a call to SD2
• Applications installed on the platform:- Application A with services ID1, ID2 belongs to SD2- Application B with service ID3 belongs to SD3
14
![Page 21: Security-by-Contract for Applications’ Evolution in Multi](https://reader031.vdocuments.site/reader031/viewer/2022020706/61fc9e579d50e757a521b85c/html5/thumbnails/21.jpg)
DTU InformaticsDepartment of Informatics and Mathematical Modelling
02234 - Autumn 2010
Possible Interactions
• Policy for security domains:- SD1 cannot call SD2- SD3 only can be called after a call to SD2
• Applications installed on the platform:- Application A with services ID1, ID2 belongs to SD2- Application B with service ID3 belongs to SD3
• New application C arrives on the platform. Desired behavior:- C will only call shareable interfaces ID1, ID2, ID3- C will only call shareable interface ID- C will only call ID2 after calling ID3
• Advanced Desired Behavior:- Information flow only TO and FROM service ID1 at any point - Call Flow TO service ID2 only after service call FROM ID3
14
![Page 22: Security-by-Contract for Applications’ Evolution in Multi](https://reader031.vdocuments.site/reader031/viewer/2022020706/61fc9e579d50e757a521b85c/html5/thumbnails/22.jpg)
DTU InformaticsDepartment of Informatics and Mathematical Modelling
02234 - Autumn 2010
Approach: Security-By-Contract
• Stolen from Meyer’s Programming-by-Contract and Model-Carrying-Code
‣ Works for Mobile Systems! (S3MS project)
• Applications come with a contract describing its security relevant behavior
‣ Security API + Shareable Interfaces
‣ Needed calls to other security domains and/or applications
‣ Allowed calls by other security domains and/or applications
‣ Forbidden calls by other security domains and/or applications
• Security policy is represented in the same model as contract, so it is possible to check contract and policy for compliance
S3MS listed in the IST Best Results!
15
![Page 23: Security-by-Contract for Applications’ Evolution in Multi](https://reader031.vdocuments.site/reader031/viewer/2022020706/61fc9e579d50e757a521b85c/html5/thumbnails/23.jpg)
DTU InformaticsDepartment of Informatics and Mathematical Modelling
02234 - Autumn 2010
SxC Workflow: Code Carries with Contract
CODE
CONTRACT
EVIDENCE OF
COMPLIANCE
LoadCode
CheckEvidence
Y/N
16
![Page 24: Security-by-Contract for Applications’ Evolution in Multi](https://reader031.vdocuments.site/reader031/viewer/2022020706/61fc9e579d50e757a521b85c/html5/thumbnails/24.jpg)
DTU InformaticsDepartment of Informatics and Mathematical Modelling
02234 - Autumn 2010
SxC Workflow: Code Carries with Contract
CODE
CONTRACT
EVIDENCE OF
COMPLIANCE
CheckEvidence
Y/N
SC POLICY
CODE
TRUSTED CONTRACT
EVIDENCE
Y
MATCH?
LoadCode
17
![Page 25: Security-by-Contract for Applications’ Evolution in Multi](https://reader031.vdocuments.site/reader031/viewer/2022020706/61fc9e579d50e757a521b85c/html5/thumbnails/25.jpg)
DTU InformaticsDepartment of Informatics and Mathematical Modelling
02234 - Autumn 2010
SxC Workflow: Code Carries with Contract
CODE
CONTRACT
EVIDENCE OF
COMPLIANCE
CheckEvidence
Y/N
SC POLICY
CODE
TRUSTED CONTRACT
EVIDENCE
Y
MATCH?
N
YCOMPLIANT
CODE
CONTRACT
EVIDENCE
RUN WITHOUT
OVERHEAD
N
NOT COMPLIANT
CODE
CONTRACT
EVIDENCE
RUN AT YOUR RISK!
LoadCode
18
![Page 26: Security-by-Contract for Applications’ Evolution in Multi](https://reader031.vdocuments.site/reader031/viewer/2022020706/61fc9e579d50e757a521b85c/html5/thumbnails/26.jpg)
DTU InformaticsDepartment of Informatics and Mathematical Modelling
02234 - Autumn 2010
SxC Workflow: Code Carries with Contract
CODE
CONTRACT
EVIDENCE OF
COMPLIANCE
CheckEvidence
Y/N
SC POLICY
CODE
TRUSTED CONTRACT
EVIDENCE
Y
MATCH?
N
YCOMPLIANT
CODE
CONTRACT
EVIDENCE
RUN WITHOUT
OVERHEAD
N
NOT COMPLIANT
CODE
CONTRACT
EVIDENCE
RUN AT YOUR RISK!
InlinePolicy
CONTRACT
EVIDENCE
RUN WITH OVERHEAD
NOT COMPLIANT
CODE
COMPLIANTWRAPPING
LoadCode
19
![Page 27: Security-by-Contract for Applications’ Evolution in Multi](https://reader031.vdocuments.site/reader031/viewer/2022020706/61fc9e579d50e757a521b85c/html5/thumbnails/27.jpg)
DTU InformaticsDepartment of Informatics and Mathematical Modelling
02234 - Autumn 2010
SxC Workflow: Contract Extracted From Code
CODE
SC POLICY
CODE
TRUSTED CONTRACT
MATCH?Y
COMPLIANT CODE
CONTRACT
RUN WITHOUT
OVERHEAD
N
NOT COMPLIANT
CODE
CONTRACT
RUN AT YOUR RISK!
InlinePolicy
CONTRACT
RUN WITH OVERHEAD
NOT COMPLIANT
CODE
COMPLIANTWRAPPING
ContractExtraction
LoadCode
20
![Page 28: Security-by-Contract for Applications’ Evolution in Multi](https://reader031.vdocuments.site/reader031/viewer/2022020706/61fc9e579d50e757a521b85c/html5/thumbnails/28.jpg)
DTU InformaticsDepartment of Informatics and Mathematical Modelling
02234 - Autumn 2010
On-Card Contract-Policy Matching
21
![Page 29: Security-by-Contract for Applications’ Evolution in Multi](https://reader031.vdocuments.site/reader031/viewer/2022020706/61fc9e579d50e757a521b85c/html5/thumbnails/29.jpg)
DTU InformaticsDepartment of Informatics and Mathematical Modelling
02234 - Autumn 2010
Off-Card Contract-Policy Matching
22
![Page 30: Security-by-Contract for Applications’ Evolution in Multi](https://reader031.vdocuments.site/reader031/viewer/2022020706/61fc9e579d50e757a521b85c/html5/thumbnails/30.jpg)
DTU InformaticsDepartment of Informatics and Mathematical Modelling
02234 - Autumn 2010
Catalogue of Possible Research Projects
![Page 31: Security-by-Contract for Applications’ Evolution in Multi](https://reader031.vdocuments.site/reader031/viewer/2022020706/61fc9e579d50e757a521b85c/html5/thumbnails/31.jpg)
DTU InformaticsDepartment of Informatics and Mathematical Modelling
02234 - Autumn 2010
1 - Formalization of Trust
X accepts Y only if Y’s behavior is trusted
![Page 32: Security-by-Contract for Applications’ Evolution in Multi](https://reader031.vdocuments.site/reader031/viewer/2022020706/61fc9e579d50e757a521b85c/html5/thumbnails/32.jpg)
DTU InformaticsDepartment of Informatics and Mathematical Modelling
02234 - Autumn 2010
1 - Formalization of Trust
X accepts Y only if Y’s behavior is trusted
Ask Nicola for a paper
Think about a possible formalization of Trust
Write down your idea
Work on the details
STEPS
![Page 33: Security-by-Contract for Applications’ Evolution in Multi](https://reader031.vdocuments.site/reader031/viewer/2022020706/61fc9e579d50e757a521b85c/html5/thumbnails/33.jpg)
DTU InformaticsDepartment of Informatics and Mathematical Modelling
02234 - Autumn 2010
2 - Security Domains
• Our prototype does not consider Security Domains yet...
‣ Extend the design of the system (new protocols) in order to take Security Domains into consideration
![Page 34: Security-by-Contract for Applications’ Evolution in Multi](https://reader031.vdocuments.site/reader031/viewer/2022020706/61fc9e579d50e757a521b85c/html5/thumbnails/34.jpg)
DTU InformaticsDepartment of Informatics and Mathematical Modelling
02234 - Autumn 2010
2 - Security Domains
Ask Nicola for a MSc Thesis + documentation
Think about a possible extension of the system
Write down your idea
Work on the details
STEPS
• Our prototype does not consider Security Domains yet...
‣ Extend the design of the system (new protocols) in order to take Security Domains into consideration
![Page 35: Security-by-Contract for Applications’ Evolution in Multi](https://reader031.vdocuments.site/reader031/viewer/2022020706/61fc9e579d50e757a521b85c/html5/thumbnails/35.jpg)
DTU InformaticsDepartment of Informatics and Mathematical Modelling
02234 - Autumn 2010
Thanks! Questions?
Nicola [email protected]
http://www2.imm.dtu.dk/~ndraEmbedded Systems Engineering (ESE) Section
DTU InformaticsTechnical University of Denmark (DTU)
“I don’t have any solution, but I certainly admire the problem”
(Ashleigh Ellwood Brilliant)