Applying MoWGLI’s prototype to the Security Certification of IT products

December 13th, 2004 MoWGLI’s Meeting

Applying MoWGLI’s prototype to the Security Certification of IT products

Eduardo Giménez

Trusted Logic SA

5, rue du Bailliage 78000 Versailles France


Use case

Common Criteria certification of IT products


IT Security Certification Scheme

SP Model

Assets, Threats

Security objectives

Security Functions and

Security requirements

Functional SPecification

High-Level Design

Low-Level Design

IMPlementation Representation

Security Target

Mowgli: semantic contents

(typechecking)

Mowgli:

neutral exchange format

(semi-formal evaluations,

developing teams)

Mowgli: model explanation

(Exploration & Rendering)


Trusted Logic Contributions

• Extracting meta-data from Coq source files

• Security Policy Model

• Transformation into UML


Mowgli’s prototype as a tool for explaining models

First Contribution:

extraction of meta-data from Coq source files


Test case

• Mowgli’s prototype tested on a formal model of a Java Card Platform– 3750 definitions

– 2000 theorems

– 300 Coq modules

– 125000 lines of source code (4Mb)

– Compressed XML output: 145Mb

• Intended user: IT security evaluator


Formal Models in Coq

Functional specification Complete & declarative

state machine

Algorithms(functions)

Implementation choices(many

languages)

High Level Design

Low level design

Implementation

Simulation proof

Security Policy Models Several

abstract state machines

Source code (C or Java)

Realizability proof


Three remarks raised by testing in the large

1. Rendering closer to Mathematics than to Programming– Records as inductive types, functions as lambda terms– Indentation not always as expected– Lack of an intermediate language for simplifying rendering modification

2. All comments in the Coq sources are lost– Common Criteria standard requires “textual” explanations– Literate programming in a javadoc style

• Coherence between models and documents• Avoiding duplication

3. Other information that could improve readability is also missed: – Coercions– Implicit arguments


Retrieving source information as meta-data

• Information present in the sources that is not part of the logical terms can be thought of as meta-data:– Comments– Coq directives like:

• Coercions• Implicit arguments• Hints• Derived vs. defined constants

• Structured comments: tags + text– Purpose of the definition– @parameter– @requirement


Generation of meta-data from Coq sources

Coq sources

RDF fileSQL

commandsXML parser

• Coercions

• Derived constants

• Opacity

Lexical analysis

(comments)

*.v

MySql

Coq compiler:

UWOBOData Base


Testing in the large

• Installing Mowgli’s prototype : not a simple task!– Heterogeneous implementation: Ocaml, Perl, MySql, XSLT, PXP, …

– No user manual

– Depends on several (unstable) Linux packages (not listed)

– Architecture not conceived for a protected environment (firewall)

• Contribution to the packaging Mowgli’s prototype:– Installation instructions

– Collecting all the Linux packages required for installation


(Place demo of meta-data extraction here)

A Coq module implementing association tables


Second Contribution

Security Policy Model document

based on Mowgli’s prototype


GlobalPlatform

Card Manager

Applet Applet Applet

Applet

Off- card Bytecode Verifier

LOAD

DELETE

SELECT

MANAGE CHANNEL

INSTALL

STORE DATA

SET STATUS

…


GlobalPlatform Security Policies

• Three security policies of GlobalPlatform were modeled: – Controlling the actions enabled for each life cycle state of the

applications and the card

– Enforcing life cycle transitions

– Card contents management: integrity of the Executable Files, consistency of application privileges

• Security policy = abstract state machine– Subject S can perform operation F on object o provided that ….

– State = attributes of each subject and object that the SP controls

– Transitions = premises of access control rules + effect on the security attributes


A document describing GlobalPlatform models in Coq

• Written using Trusted Logic’s editing tool (FDD)

• Output in XHTML + minor modifications by hand

• XSLT post-processing of three directives:

– Inlinning of Coq definitions<ht:DEFINITION uri="component_update.con" as="Definition"/>

– Hyperlinks to other definitions<a helm:helm_link="href" href=“…” > … </a>

– Silent directives for opening Coq sections<ht:SECTIONuri="cic:/…./Records/Components/Component_Update/">


Some conclusions from the exercise

• A high level tool for explaining formal definitions in English– Automatic processing of logical connectives and main Coq

constructions

– Spelling of the each atomic predicate specified by the user

– XSLT transformations are too complicated and poor: what language for describing rendering?

• An editing tool for writing formal Coq documents?


(Place demo of the SPM document here)

SPM document of VISA GlobalPlatfom

Article.url


Mowgli’s XML output as an exchange format for formal models

Third contribution:

a translator fromm Coq to UML


Exchanging models between environments

• Motivations:– XML format of Coq terms as a “neutral” exchange format– UML is a widely accepted standard in industry– UML provides a language to communicate with developers – UML is accepted as “semi-formal” specifications (required for some

assurance levels in CC evaluations)– Linking formal models to input models provided by the clients

• Goal: automatic integration of formal models in Coq into an UML environment (Rational Rose).

• Data structures, predicates and comments in UML, theorems as links to Mowgli’s prototype.


Unified Modeling Language(UML)

Class A•public short x•private void f(int x)

Class B•public static C z

Class D

generalizes

depends on

Package P

Class C associated to


Translation Principles for informative objects

• Coq Module

• Coq T:Set

• Coq T(A:Set) : Set

• Parameter c: T

• Coq R{x1:T1;…xn:Tn}

• Coq function f(x1:T1,… xn:Tn)

• Coercion f : A B

• UML Package• UML Class T• UML parameterized class T[A]• UML static field c of class T• UML instance fields x1, … xn

• UML method f attached to class C if C is « close » to f, static method of default class otherwise.

• Class B generalizes class A


Translation Principles for predicates

• P (x1:T1,… xn:Tn) : Prop

• Interpreted as a sub-set of the product T1× … Tn.

• A proof is a tuple (t1, … tn)

• A constructors of an inductive predicate is a function defining a tuple in T1× … Tn.

• A theorem is a function built from constructors.

• UML Class P (no parameters) with instance fields x1:T1,… xn:Tn.

• A proof is an object of class P with values x1:=t1 … xn:=tn

• A constructor is a class constructor.

• A theorem is a method defined in some class.

• Only predicates are translated, to visualize the relations between data-structures.


Example

The inductive definition:

Inductive P : nat -> bool -> Prop := C : x:nat . x>0 P (S x, true).

is translated into the class:

class P { public nat n; public bool b; C(nat x; less p) { n:=x+1; b:=true} }


Coq2UML’s Architecture

XML

CICenvironment

ocamlinternal

structures

XMI

UWOBO

Translator XML dump

Rose add-in

Coercions,

derived constants,

textual descriptions

Formal definitions

Mowgli’s parser

+

Topological sort

Interface

inference

*.con

*.theory


Making diagrams more readable

• Derived constants are omitted– Elimination principles

– Record projections

• « Local » class diagrams by Coq module

• Computing a minimal interface for each Coq module (experimental):– Only « public » constants used in other modules are considered

– A defined constant is made abstract when it is not necessary to unfold its definition for typing other modules (requires modified typing)

– An inductive type is made abstract when its constructors are never used in the other modules


(Place demo of UML translator here)

UML description of GlobalPlatform and association lists

Rational Rose Modeler Edition.lnk

Documents

Applying MoWGLI’s prototype to the Security Certification of IT products