Architecture d`identité convergente pour l`internet de nouvelle

Transcription

Architecture d'identité convergente pour l'internet de nouvelle génération basée sur ll é é ti b é
des microcontrôleurs sécurisés
des microcontrôleurs sécurisés
Pascal Urien
Professeur à Télécom ParisTech, UMR 5141
Co Fondateur de la société
Co‐Fondateur
de la société EtherTrust
Pascal.Urien@telecom‐paristech.fr
[email protected]
Pascal Urien, Crypto’Puces2011, Porquerolles le 12 mai 2011
1
Agenda
•
•
•
•
•
De la carte SIM au Secure Element
De
la carte SIM au Secure Element
L’émergence du Cloud Computing
L’identité dans le Cloud
Vers un modèle d’Identité
Vers un modèle d
Identité Convergent
Convergent
Quelles performances, Quelles limites ?
2
De la carte SIM au
D
l
SIM
Secure Element
Secure Element
3
Au sujet de la carte SIM….
Au sujet
de la carte SIM
• 1988, Invention de la carte i d l
SIM
• 1991, premières SIM commercialisées
• 1997, première carte java
• 2002, premières cartes 2002 premières cartes
USIM
• 2009, premiers déploiements LTE
4
LL’ère
ère des Secure Elements
des Secure Elements
•
•
LLe Nexus S comporte
N
S
t un routeur
t
NFC
NFC sécurisé
PN65N =PN544+PN072 ? Pascal Urien, Crypto’Puces2011, Porquerolles le 12 mai 2011
5
•
•
•
•
Secure MX: PN532
OS JAVA JCOP + GP
L’identité
Crypto‐processeur (3xDES, AES, RSA, ECC) est un CC EAL5+
programme
Security Certificates EMVCo
6
http://www gartner com/it/page jsp?id=1622614
http://www.gartner.com/it/page.jsp?id=1622614
Plus d’un milliard de SmartPhones
en 2015
296,647 467,701 630,471 1,104,898
8
http://www.etforecasts.com/products
/ES_pcww1203.htm
Deux
milliards de PCs en 2015
9
LL’émergence
émergence du Cloud du Cloud
Computing
10
Petite histoire de l’Internet 1/2
•
•
•
•
1970
– Les cinq premiers nœuds Internet : UCLA, Stanford, UC Santa Barbara, University of Utah BBN
Utah, BBN
1974 – Premières spécifications du protocole TCP, RFC 675 Vint Cerf.
RFC 675, Vint
Cerf
Janvier 1984
– Le premier réseau ARPANET TCP/IP est opérationnel, et comporte 1000 nœuds.
opérationnel, et comporte 1000 nœuds.
Janvier 1986
– IETF 1, San Diego, 21 participants.
11
Petite histoire de l’Internet
Petite histoire de l
Internet 2/2
2/2
• Juillet 1994
J ill t 1994
– A Border Gateway Protocol 4 (BGP‐4), RFC 1654
• Mai 1994, NAT
– RFC 1661, The IP Network Address Translator (NAT)
Address Translator (NAT).
• 1989, Invention du WEB
– Tim Barner Lee réalise les premiers serveurs
i
et clients HTTP en 1990
• 1999, Wi‐Fi, IEEE 802.11
Tous les smartphones intègrent une interface Wi Fi
intègrent une interface Wi‐Fi
12
GOOGLE: Une société fondée en GOOGLE
U
iété f dé
1998 par Larry Page et Sergev Brin
DNS Server
Google Web Server
Index
I Index Servers
Index Servers
d SServers
Index Servers
Document Servers
Document
DDocument Servers
Document Servers
tServers
S
13
359 racks
• 31,654 machines
• 63,184 CPUs
• 126,368 Ghz of processing power
• 63 184 Gb of RAM
• 63,184 Gb
of RAM
• 2,527 Tb of Hard Drive space
1792 megabytes of memory
366 gigabytes of disk storage
2933 megahertz in 10 CPUs
CorkBoard
Google Cluster
GOOGLE CIRCA 1999
1997
1999
2004
14
2006
http://www.google.com/datacenter/thedalles/index.html
http://www.youtube.com/watch?v=zRwPSFpLX8I&NR=1
http://www.youtube.com/watch?v
zRwPSFpLX8I&NR 1
Au moins 12 data center de grande capacité
GOOGLE data center (2008)
(
)
15
http://harpers.org/media/s
htt
//h
/ di /
lideshow/annot/2008‐
03/index.html
• 3 bâtiments de 6400m2 (2 construits)
• 1 million de serveurs
• 250 octets (penta octet, 1024 To, 1 million de Go)
• 103 MW (un réacteur nucléaire produit entre 1000 et 1500 MW))
• La consommation électrique d’une ville de 80,000 habitants
,
En France le prix de revient du MW/h est de l’ordre de 5€, le prix de vente aux particuliers est de l’ordre
particuliers est de l
ordre de 75€
de 75€
100MW, 200,000 €/jour
16
17
LL’identité
identité dans le Cloud
dans le Cloud
18
Et l’identité
Et l
identité du Cloud…le mot de passe
du Cloud le mot de passe
Chiffre d’affaire
Microsoft 60,4 M$
GOOGLE 21,8 M$
SalesForce 1,3 M$
Facebook
1,0 M$
19
Pourquoi le login/mot de passe
le login/mot de passe ?
• Un héritage de l’informatique traditionnelle pour la gestion des comptes ut sateu s
utilisateurs
• Le mot de passe est une clé symétrique partagée avec le serveur
– Il devrait y avoir autant de secrets que de serveurs, mais en pratique c’est difficile à mettre en œuvre pour un utilisateur humain
difficile à mettre en œuvre pour un utilisateur humain.
• NETSCAPE a inventé le protocole SSL en 1995, pour sécuriser les sessions HTTP
– Le serveur est identifié par un certificat
Le serveur est identifié par un certificat
– Le client est identifié par le couple login/mot de passe
– La session SSL sécurise le mot de passe
• Le cookie a été inventé en 1995 avec la version 2 de Netscape
L
ki été i
té 1995
l
i 2d N t
– Le cookie réalise l’authentification/autorisation d’une session HTTP, c’est‐à‐dire d’une suite de requêtes, il est inséré dans l’en tête HTTP
• Le Session ID (sid) joue également le rôle du cookie, il peut être inséré dans ( )
é l
l ôl
k l
ê
éé
l’entête d’une requête GET HTTP ou dans le corps du message pour une méthode POST
– En PHP les cookies et les sid (SessionID) jouent le même rôle d’identifiant de session
20
Comment sécuriser un mot de passe
Comment sécuriser
un mot de passe
• HTTP digest, RFC 2617
– KD(secret, data) = Hash(secret || KD(secret data) = Hash(secret || ":"
: || data )
|| data )
– Déployé, mais pas utilisé en pratique
• RFC 4279, TLS‐PSK (pre
(p shared key)
y)
– PreMasterSecret = nonce | PSK
– Le nonce est transmis chiffré avec la clé publique du serveur
– Pas de déploiement connu
Pas de déploiement connu
• Le One Time Password (OTP)
– hash(timestamp
(
p || secret), par exemple RSA SecureID
), p
p
– MAC(compteur, secret), RFC 4226 , "HOTP: An HMAC‐Based One‐
Time Password Algorithm"
– MAIS sensible aux attaques MIM (Man In the Middle), autrement MAIS sensible aux attaques MIM (Man In the Middle) autrement
dit vol d’un OTP.
• Solution possible
– U
Utiliser un OTP comme le PSK d’une session TLS‐TSK. Le serveur ili
O
l SK d’
i
LS SK L
estime les valeurs possibles de l’OTP.
21
Un exemple millénaire d’authentification statique
22
Technologies de Gestion d’Identités
•
Un ensemble de plateformes hétérogènes
– WS
WS_, WEB Security : introduit la notion de TOKEN (jeton), de claim (revendication) et de POP WEB S
it i t d it l
ti d TOKEN (j t ) d l i (
di ti ) t d POP
(Proof‐of‐Possession Token)
– Liberty Alliance, fédération d’identité, définition du concept d’Identity Provider (IdP). Adoption du standard SAML.
– SAML, Security Assertion Markup Language, introduit la notion d
SAML Security Assertion Markup Language introduit la notion d’assertion
assertion SAML (un jeton réalisé SAML (un jeton réalisé
en syntaxe XML), et de transport (Protocol Binding)
– InfoCard(Microsoft), un Information Card est un artefact qui contient des métadonnées sous la forme d’un jeton prouvant la relation entre un Identity Provider et un utilisateur
– OPENID, un standard de SSO (Single Sign
OPENID un standard de SSO (Single Sign On), utilisant implicitement la notion de jeton sécurisé
On) utilisant implicitement la notion de jeton sécurisé
•
Dans la pratique, le mot de passe reste roi pour l’authentification
23
Authentification Dynamique: une illustration du Proof Of Possession
illustration du Proof Of Possession
GET /dir/index.html
HTTP/1.0 401 Unauthorized
WWW‐Authenticate:
WWW
Authenticate: Digest Digest
realm="[email protected]", qop="auth,auth‐int", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", ,
opaque="5ccc069c403ebaf9f0171e9517f40e41" GET /dir/index.html Authorization: Digest username="Mufasa", realm="[email protected]", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="/dir/index.html", qop=auth, nc=00000001, cnonce="0a4f113b", response="6629fae49393a05397450978507c4ef1", "6629f 49393 05397450978507 4 f1"
opaque="5ccc069c403ebaf9f0171e9517f40e41" Possible, mais pas Possible,
mais pas
normalisé !!
r1
ID 2 f( 1 2 )
ID, r2, f(r1,r2,…)
24
Le Token: un cookie d’Autorisation
Le Token: un cookie d
Autorisation
•
Un Token (jeton) est une liste de revendications (claims)
– U
Un ensemble d’information sécurisé, exprimé à l
bl d’i f
i
é ié
i é à l ’aide d’une syntaxe XML
’ id d’
XML ou URLEncoded
•
Délivrance de Tokens
•
– Nécessite une preuve d
Nécessite une preuve d’identité
identité de l
de l’internaute
internaute
– Mot de passe, certificat, …
Vérification de Tokens
Claim Request
SERVICE
Le projet
SecFuNet
Check
OK
TOKEN
VERFICATOR
Claim Response
Request
Security
Association
USER
ID
Response
Proof
TOKEN
GENERATOR
25
Quelques Architectures
q
S G
V
S
U
V
(HSM)
Login / Password
S
U
V
Security
Association
G
OPENID
S
V
SAML
INFOCARD
U
G
EMV
U
G
26
Exemple de Claim Request, OpenID
• Le service (consumer) délivre un Claim Request à l’intention de l’Identity Provider, à l’aide d’un mécanisme de redirection HTTP.
é i
d
di
i
Consumer
192.168.2.44
192.168.2.35
<html><head><title>OpenId transaction in progress</title></head>
transaction in progress</title></head>
<body onload='document.forms[0].submit();'>
<form accept‐charset="UTF‐8" enctype="application/x‐www‐form‐urlencoded" id="openid_message" action="http://192.168.2.44/openid/examples/server/server.php" method="post">
<input type="hidden" name="openid.ns" value="http://specs.openid.net/auth/2.0" />
<input type="hidden" name="openid.ns.sreg" value="http://openid.net/extensions/sreg/1.1" />
i
tt
"hidd "
"
id
" l
"htt //
id t/ t i /
/1 1" /
<input type="hidden" name="openid.ns.pape" value="http://specs.openid.net/extensions/pape/1.0" />
<input type="hidden" name="openid.sreg.required" value="nickname" />
<input type="hidden" name="openid.sreg.optional" value="fullname,email" />
<input type="hidden" name="openid.pape.preferred_auth_policies" value="" />
<input type="hidden" name="openid.realm" value="http://192.168.2.35:80/openid/examples/consumer/" />
<input type="hidden" name="openid.mode" value="checkid_setup" />
<input type="hidden" name="openid.return_to" value="http://192.168.2.35:80/openid/examples/consumer/finish_auth.php?janrain_nonce=2009‐03‐17T09:07:14ZGoN7wY" />
<input type="hidden"
<input type
hidden name
name="openid
openid.identity
identity" value
value="http://192
http://192.168.2.44/openid/examples/server/server.php/idpage?user
168 2 44/openid/examples/server/server php/idpage?user=moi"
moi />
/>
<input type="hidden" name="openid.claimed_id" value="http://192.168.2.44/openid/examples/server/server.php/idpage?user=moi" />
<input type="hidden" name="openid.assoc_handle" value="{HMAC‐SHA1}{49bf5e64}{Va0OCQ==}" />
<input type="submit" value="Continue" />
</form>
< i t>
<script>var elements
l
t = document.forms[0].elements;for
d
tf
[0] l
t f (var i = 0; i < elements.length; i++) { elements[i].style.display
( i 0 i< l
t l th i++) { l
t [i] t l di l = "none";}
"
"}
</script></body></html>
27
Exemple de Claim Response, OpenID
• Le Identity Provider délivre un token au service (Consumer), à l’aide d’un mécanisme de redirection HTTP.
HTTP/1 1 302 Found
HTTP/1.1 302 Found Date: Tue, 17 Mar 2009 09:07:28 GMT Server: Apache/2.2.6 (Win32) DAV/2 mod_ssl/2.2.6 OpenSSL/0.9.8g mod_autoindex_color PHP/5.2.5 X‐Powered‐By: PHP/5.2.5 Cache‐Control: no‐store, no‐cache, must‐revalidate, post‐check=0, pre‐check=0 P
Pragma: no‐cache h
C
Consumer
192.168.2.44
Expires: Thu, 19 Nov 1981 08:52:00 GMT location: http://192.168.2.35:80/openid/examples/consumer/finish_auth.php?
janrain_nonce=2009‐03‐17T09:07:14ZGoN7wY
192.168.2.35
&openid.assoc_handle={HMAC‐SHA1}{49bf5e64}{Va0OCQ==}
&openid.claimed_id=http://192.168.2.44/openid/examples/server/server.php/idpage/user=moi
&openid.identity=http://192.168.2.44/openid/examples/server/server.php/idpage/user=moi
&openid.mode=id_res
&openid.ns=http://specs.openid.net/auth/2.0
&openid ns sreg=http://openid
&openid.ns.sreg
http://openid.net/extensions/sreg/1.1
net/extensions/sreg/1 1
&openid.op_endpoint=http://192.168.2.44/openid/examples/server/server.php
&openid.response_nonce=2009‐03‐17T09:07:28Z2Z6LCL
&openid.return_to=http://192.168.2.35:80/openid/examples/consumer/finish_auth.php/janrain_nonce=2009‐03‐17T09:07:14ZGoN7wY
&openid.sig=HUBr4K7Ff51FHCywZFux2IcZ9Xg=
&
&openid.signed=assoc_handle,claimed_id,identity,mode,ns,ns.sreg,op_endpoint,response_nonce,return_to,signed,sreg.email,sreg.fullname,
id i d
h dl l i d id id tit
d
d i t
t
t i d
il
f ll
sreg.nickname
&[email protected]
&openid.sreg.fullname=Example+User
&openid.sreg.nickname=example Connection: close Content‐Length: 0 Content‐Type: text/html
28
Comment Transférer un Token
Comment Transférer un Token
•
Problème
company.com
– Le service et le générateur de jetons ne sont pas toujours dans le même domaine
j
d
l
ê
d
i
•
Infrastructure privée
Idt.company.com
– Service.company.com et Idt.company.com sont service.company.com
p y
deux sous domaines de company com
deux sous domaines de company.com
– Il est possible d’échanger un cookie entre sous Cookie
domaines
•
Infrastructure publique
Infrastructure publique Set‐Cookie
Set
Cookie
– Les cookies inter‐domaines sont interdits
– Une mécanisme couramment utilisé est la redirection HTTP (voir par exemple OPENID) avec un point de pivot via le navigateur de l’utilisateur d
l
d l’ l
(USER)
• Cette approche engendre un problème de privacy en raison du lien entre le service et le serveur d’ h ifi i
d’authentification
•
Redirect
service.com
i
Le navigateur du client est le point central d’une architecture de gestion d’identité dans un Redirect
contexte Cloud Computing
contexte Cloud Computing
– En particulier il assure le stockage des Tokens
Idt.com
Redirect
29
Vers un modèle d
Vers
un modèle d’identité
identité convergent
30
Un modèle d’identité
Un modèle d
identité pour le Cloud
pour le Cloud
• L’identité s ’appuie sur une pile SSL embarquée
– Authentification
Authentification mutuelle forte basée sur des certificats X509 et des mutuelle forte basée sur des certificats X509 et des
clés RSA privée
• De multiples facteurs de formes
– Clés USB, sticker 3G, cartes SIM, cartes sans contact, mobile NFC, Android, RIM…
• Gestion du cycle de vie de l
Gestion du cycle de vie de l’identité
identité
– Via un serveur d’identité (ID‐Provider) dont les accès sont sécurisés par des sessions SSL/TLS avec mutuelle authentification forte.
• Glue logique avec le navigateur
Glue logique avec le navigateur
SSL Id tit
SSL Identity
– A l’aide d’un proxy
• Mécanismes d’authentification
éca s es d aut e t cat o
– Single Sign On: OPENID
– PKI: SSL/TLS
– VPN: EAP‐TLS
VPN EAP TLS
BOB s
BOB’s
Certificate
BOB
CA
Certificate
BOB’s RSA Private Key
Private Key
31
L’identité pour les opérateurs
Subject= bob
USIM Module
‐ CPU, RAM, FLASH
CPU RAM FLASH
‐ Crypto‐processor
‐ Java Virtual Machine
proxy.exe
Bob’s
Certificate
CA
Certificate
RSA RSA
Private Key
SSL/TLS embedded Stack
Micro SD Micro
SD
Memory
BOB’ ID: http://www.server.com/openid/pascal/s
erver/server.php/idpage?bob
3G Dongle
3G
D
l
USIM + Micro SD memory
OpenID Provider
Ordin ateur central
32
LL’identité
identité pour les Serveurs
pour les Serveurs
• TCP/IP connectivity
TCP/IP connectivity
• 32 smart cards/ boards
• Up to 450 smart cards/rack
RADIUS
Server
Internet
GRID
Server
EAP‐TLS Smart C dA
Card Array
33
LL’Identité
Identité pour les prépaiements
pour les prépaiements
• 10 millions de clients
• 3 milliards €
3 milliards € de titres/ans
de titres/ans
34
Identité p
pour l’Internet Of Things:
g
HIP‐RFID
35
Quelles performances ?
Q ll li it ?
Quelles limites ?
36
Calcul de performances pour le protocole TLS
• For the TLS full mode
– processing of 230 MD5 and 230 SHA1 blocs, one RSA encryption with a private key, one RSA decryption and one encryption with a public key. Furthermore 2500 bytes of information are exchanged.
• For the TLS resume mode
– processing of 75 MD5 and 75 SHA1 blocs; 250 bytes of information are exchanged
information are exchanged.
Tfull = 230 (TMD5+TSHA1)+ TRSAPRIV + 2 TRSAPUB + N TIO +TSF
Tresume = 75 (T
( MD5+TSHA1))+ N. TIO IO + TSR
– where N is the number of information bytes exchanged, and TSF
and TSR the residual time induced by embedded software instructions. • For the Javacard
Tfull = 2,0s TSF = 0,7s ‐ Tresume= 0,50s; TSR= 0,35s
• For the USIM
h S
Tfull = 4,3s TSR= 2,65s ‐ Tresume=1,65s; TSR= 1,45s
37
Détails de performances
de performances
38
Comparaison systèmes embarqués et JavaCard
Linksys WRT‐
54G V 3
54G V. 3 Bogo
mips
MD5
Ko/s
SHA1
Ko/s
DES
Ko/s
3xDES
Ko/s
AES
128
Ko/s
RSA 2048 sign
/s
RSA 2048
Verify
/s
BCM 3302
5,000 3,300
1,700 420
1530
2 67
51
1900
2
(1024)
40
(1024)
215
Intel
M h b d
Motherboard
D945GCLF2
Intel 183,000 83,000 18,000
A
Atom
330
330 6,400 24,500
3200
Java
card
?
128
64
‐
4
6
39
Eléments Physiques
•
•
•
•
•
•
•
‐12
Permittivité du vide, ε0= 8,854 10
,
,
Metal
Permittivité du Silicium ε= εr x ε0 = 11,68 x ε0
Charge d’un électron q= 1,6 10‐19
Isolant (SiO2)
Charge commuté (Qb) de Ne électrons, Qb = Ne x q
Silicium
Energie stockée dans une capacité:
Wb= ½ x CG x VH2 = ½ Qb x VH = ½ x Ne x q x VH
Energie dissipée par une transition d’un électron sous une tension de 1V: 19 W
1 6 10‐19
1,6 10
Dimensions d’un transistor
– Longueur (L) de 1 à 3 μm, largeur (W) de 0,2 à 100 μm, épaisseur de l’isolant (tox) de 2 à 50 nm
– C = L x W x ε / tox
– soit 103 10‐15 pour L= 1 μm, W=10 μm, tox= 10 nm
• Sous 1V la charge associée est d’environ 640,000 électrons •
Une commutation (1/0) d’une porte NAND dissipe une énergie W
( / )
p
p
g
b
Vo= VH x (1 ‐ H(Ve1‐ ½ VH) x H(Ve2‐ ½ VH) )
/ )
VH (1‐e
(1 e‐t/tr
V 1
Ve
RG
Ve2
VH e‐t/tr CG
Vs # Vo(1‐t/tr)
tr= RGCG
40
Puissance Consommée
Puissance Consommée
• Une commutation (1/0) d’une porte NAND dissipe une énergie Wb
• Si Nc commutations de portes NAND, en moyenne, p
,
y
,
sont nécessaires pour un calcul, avec Fc
calculs/seconde, alors l’énergie consommée (P
g
c) est égale : q H
Pc = Fc x Nc x Wb = Fc x Nc x ½ x Ne x q x V
• Exemple
– 100
100,000 commutations (N
000 commutations (Nc) sous un 1V (V
) sous un 1V (VH ) de 100,000 (Ne) ) de 100 000 (Ne)
électrons (q=1,6 10‐19), avec Fc=109 (1GHz)
– Pc = 10
109 x 10
x 105 x ½ x 10
x ½ x 105 x 1,6 10
x 1,6 10‐19 = 0,8 Watt
0,8 Watt
41
Exemple d
d’implémentation
implémentation Hardware
•
"Hardware implementation of the RC4 Stream Cipher", 2004, P. Kitsos, G. "Hardware
implementation of the RC4 Stream Cipher" 2004 P Kitsos G
Kostopoulos, N. Sklavos, and 0. Koufopavlou
– 4 x256‐byte RAM, 4x 8‐bit register, 3x 8‐bit adder, 2‐bit MUX, 12950 NAND gates
– Init: 768 cycles
Init: 768 cycles
– Cipher/byte : 3 cycles
•
"Design and Implementation of a SHA‐1 Hash Module on FPGAs“, Kimmo
Järvinen (2004)
–
–
–
–
–
•
throughput = block size × clock frequency /clock cycles per block
Slices 1,275, equivalent gate count 25,467
Max. clock frequency: 117.5 MHz
q
y
Latency of a SHA‐1 round: 698 ns
Throughput: 734 Mbps
10,000 commutations (N
,
( c)) sous un 1V (V
( H )) de 100,000 (Ne) électrons (q=1,6 ,
( )
(q ,
‐19
7
10 ), avec Fc=10 (10 MHz)
– Pc = 108 x 104 x ½ x 105 x 1,6 10‐19 = 1 mW
– RC4: 3,300 Ko/s
– SHA1: 9,000 Ko/s
Les performances actuelles sont /150
42
Quelques Références
Quelques Références
•
•
•
•
•
•
Urien, P.;
Urien
P "An OpenID Provider based on SSL Smart Cards",
Cards" Consumer
Communications and Networking Conference, 2010. CCNC 2010. 7th IEEE 9‐
12 Jan. 2010, BEST Demonstration Award
Urien Pascal; Marie,
Urien,
Marie Estelle; Kiennert,
Kiennert Christophe; "An
An Innovative Solution
for Cloud Computing Authentication: Grids of EAP‐TLS Smart Cards",
Conference on Digital Telecommunications (ICDT), 2010 Fifth International,
13‐19 June 2010, Best Paper
P.Urien & All, "HIP support for RFIDs", draft‐irtf‐hiprg‐rfid‐00, June 2010
Dorice Nyamy, Pascal Urien, "HIP‐TAG, a New Paradigm for the Internet of
Things", IEEE CCNC 2011, January 9‐12 2011
Pascal Urien, “Convergent Identity: Seamless OPENID services for 3G
dongles using SSL enabled USIM smart cards”, IEEE CCNC 2011, January 9‐12
2011
P
Pascal
l Urien,
Ui
M
Marc
P
Pasquet,
Ch i
Christophe
h Kiennert,
Ki
"A breakthrough
b kh
h for
f
prepaid payment: end to end token exchange and management using secure
SSL channels created by EAP‐TLS smart cards", International Symposium on
Collaborative Technologies and Collaborative Technologies and Systems
(CTS), 2011, May 23‐27, 2011
43

Architecture d`identité convergente pour l`internet de nouvelle

Transcription

Documents pareils

Vélo à Porquerolles - La Bastide Ramatuelle

Horaire des Navettes Giens- La Tour Fondue—Porquerolles

exposé - Laure

hotel la garissade

Parvis de la defense - Archives orales

WE CELIB LA LONDE.pub

Demonstration culinaire Aussignac_impr_201201

CV Restauration

Local commercial Tourcoing Brun Pain 70 m²