SLIDE 1 Visibl e Metho ds Card issuing Unive rsity intern al users Foreign users Card holder Data element Stude nt’s admin istrati
Staff admin istrati
Guest admin istrati
Unive rsity consol idatio n Unive rsity depen ding users Other s
Application Profile (AP) cwr cwr cwr cwr r r r r r Card ID (CID) cr cr cr cr r r r Certificate card holder – encrypt (CHE) cwrv r cwr cwr rv Certificate card holder – sign (CHS) cwrv cwr cwr cwr rv Certificate card holder – auth (CHA) cwrv cwr cwr cwr rv Certificate Trust Center (CTC) cwrv cwr cwr cwr rv Date of Expire – Begin (DEB) cwr cwr cwr cwr r r r r r Date of Expire – End (DEE) cwr cwr cwr cwr r r r r r List of DES-Keys (DES) cw cw cw cw Card holder identification (OM) cr cr cr cr r r r Status-group (PS) cwr cwr cwr cwr r r r Personal Identification Number (PIN) cw c c c w PIN Failure counter (FVZ) c c c c Secret Key – encrypt (SKE) cwd cw cw d
AP
c r w
50 48 49
CID
c r
46 47
CHS
c r w v
41 40 39 38
CHA
c r w v
37 36 35 34
CTC
c r w v
32 33 31 30
DEB
c r w
29 28 27
p
26
1 0 1 0 0 0 0 0 0 1
CHE
c r w v
44 43 42 45
PKI based Access Control with Attribute Certificates for Data held on Smartcards
Lutz Suhrbier, Thomas Hildmann Technical University of Berlin Research Center for Network and Multimedia Technology PRZ / FSP-PV
SLIDE 2 Content
– State of the art
– Attribute certificates – Security level – Integration of security level into certificates
– Operating sequence : Data access
- More advanced access control
– Delegation of rights and credentials
SLIDE 3 Current problems
– Access control using symmetric keys (common secret) – Problem of key-exchange (old known problems) – Only flat 1:1 mapping of permissions and keys – Keeping the keys secret – A compromise of a single key compromises the whole infrastructure – Can not be used on insecure terminals because of loosing the control of the key
- How to realize access control using a public-key infrastructure?
SLIDE 4 Visibl e Metho ds Card issuing Unive rsity intern al users Foreign users Card holder Data element Stude nt’s admin istrati
Staff admin istrati
Guest admin istrati
Unive rsity consol idatio n Unive rsity depen ding users Other s
Application Profile (AP) cwr cwr cwr cwr r r r r r Card ID (CID) cr cr cr cr r r r Certificate card holder – encrypt (CHE) cwrv r cwr cwr rv Certificate card holder – sign (CHS) cwrv cwr cwr cwr rv Certificate card holder – auth (CHA) cwrv cwr cwr cwr rv Certificate Trust Center (CTC) cwrv cwr cwr cwr rv Date of Expire – Begin (DEB) cwr cwr cwr cwr r r r r r Date of Expire – End (DEE) cwr cwr cwr cwr r r r r r List of DES-Keys (DES) cw cw cw cw Card holder identification (OM) cr cr cr cr r r r Status-group (PS) cwr cwr cwr cwr r r r Personal Identification Number (PIN) cw c c c w PIN Failure counter (FVZ) c c c c Secret Key – encrypt (SKE) cwd cw cw d Secret Key – sign (SKS) cs c c c s Secret Key – auth (SKA) cwa cw cw cw a
SLIDE 5 Attribute certificates
- Attribute certificates are just like public-key certificates with the
following differences: – Instead of a public-key they contain structured data which can be used for role, group, access control or other mappings. – An attribute certificate is a binding of attribute data to a subject. – A public-key certificate is a binding of a public-key to a subject. – Both are signed by a certification authority which guarantees the correctness of the binding.
SLIDE 6
Attribute Certificates vs. Public-Key Certificates
attributecertificate data issuer signature validity subject attribute 1 attribute 2 Public-keycertificate data issuer signature validity subject public-key
SLIDE 7
We are using combined certificates
combinedcertificate data issuer signature validity subject public-key attribute 1 attribute 2 attributecertificate data issuer signature validity subject attribute 1 attribute 2 Public-keycertificate data issuer signature validity subject public-key
SLIDE 8 Security level
AP
c r w
50 48 49
CID
c r
46 47
CHS
c r w v
41 40 39 38
CHA
c r w v
37 36 35 34
CTC
c r w v
32 33 31 30
DEB
c r w
29 28 27
p
26
1 1 0 1 1 1 0 0 1 1 0 0 1 1 1 0 1 1
CHE
c r w v
44 43 42 45
1 1
DEE
c r w
25 24 23
p
22
OM
c r
18 17
p
16
PS
c r w
15 14 13
p
12
DES
c e w
21 20 19
PIN
c w
10 11
FV Z
c
09
SKE
c w
08 07
d
06
SKS
c s
04 05
SKA
c w
03 02
a
01
1 1 0 1 0 0 1 1 0 0 0 0 0 0 0 1 0 0 0
SLIDE 9 Visibl e Metho ds Card issuing Unive rsity intern al users Foreign users Card holder Data element Stude nt’s admin istrati
Staff admin istrati
Guest admin istrati
Unive rsity consol idatio n Unive rsity depen ding users Other s
Application Profile (AP) cwr cwr cwr cwr r r r r r Card ID (CID) cr cr cr cr r r r Certificate card holder – encrypt (CHE) cwrv r cwr cwr rv Certificate card holder – sign (CHS) cwrv cwr cwr cwr rv Certificate card holder – auth (CHA) cwrv cwr cwr cwr rv Certificate Trust Center (CTC) cwrv cwr cwr cwr rv Date of Expire – Begin (DEB) cwr cwr cwr cwr r r r r r Date of Expire – End (DEE) cwr cwr cwr cwr r r r r r List of DES-Keys (DES) cw cw cw cw Card holder identification (OM) cr cr cr cr r r r Status-group (PS) cwr cwr cwr cwr r r r Personal Identification Number (PIN) cw c c c w PIN Failure counter (FVZ) c c c c Secret Key – encrypt (SKE) cwd cw cw d Secret Key – sign (SKS) cs c c c s Secret Key – auth (SKA) cwa cw cw cw a
AP
c r w
50 48 49
CID
c r
46 47
CHS
c r w v
41 40 39 38
CHA
c r w v
37 36 35 34
CTC
c r w v
32 33 31 30
DEB
c r w
29 28 27
p
26
1 0 1 0 0 0 0 0 0 1
CHE
c r w v
44 43 42 45
SLIDE 10 Integration of security level into certificates
- Security level is a base64 encoded bitmap concatenated to the
subject name – No extensions are needed to a standard X.509v3 certificate – Subject names are clear text fields and are human readable without any needed of additional software cn=reregistration.tu-berlin.de,o=Technische Universitaet Berlin,c=DE,sl=00000001fAngkH08
SLIDE 11
Operating sequence : Data access
1:(req,rcert)=sym_decrypt(cryptreq,skey) 2:verify_cert(rcert,CTC) 3:rpubkey =extract_public_key(rcert) 4:verify_data(req,rpubkey) 5:seclevel =extract_seclevel(rcert) 6:return =execute_req(req,seclevel) 7:signedreturn =sign(return,SKA) 8:cryptreturn =asym_encrypt(signedreturn,rpubkey)
SLIDE 12
- 1. The foreign-university requires access to data
elements Smartcard Foreign University Home University
getData(x)
SLIDE 13
2: Generate random number and send to foreign- university Smartcard Foreign University Home University
1:rnd =randomize() 2:reqestForCredential(rnd)
SLIDE 14
3: forwarding request for credential Smartcard Foreign University Home University
reqestForCredential (rnd,getData(x))
SLIDE 15
4: home-university is proving the permission Smartcard Foreign University Home University
1:checkPermission(getData(x)) 2:cred =signCredential (HomeCERT,rnd, getData(x)) 3:cred
SLIDE 16
5: foreign-university is sending credential to smartcard Smartcard Foreign University Home University
cred
SLIDE 17
6: validate rnd, check signature and security level, encrypt and return Smartcard Foreign University Home University
1:(HomeCERT,getData(x))=checkSignature(req) 2:**thedataaccessalgorithmasseebefore** cryptreturn =asym_encrypt(signedreturn,HomeCERT) 3:cryptreturn
SLIDE 18
7: foreign-university is sending the encrypted values to the home-university Smartcard Foreign University Home University
cryptreturn
SLIDE 19
8: home-university decrypts and re-encrypts for foreign- university Smartcard Foreign University Home University
1:signedX =decrypt(HomePRIV,cryptreturn) 2:funiCryptedSignedX =encrypt(ForeignUniCERT, signedX) 3:funiCryptedSignedX
SLIDE 20 Conclusion
- Using combined attribute-/public-key-certificates enables a
flexible and effective protection of data elements on smartcards.
- This infrastructure was implemented successfully at Technical
University of Berlin.
- There are solutions for environments constituted by several
- rganisations with different access rights.
SLIDE 21 For contact and further information / discussion
http://www.prz.tu-berlin.de/~lusu/
http://www.prz.tu-berlin.de/~hildmann/
- German Homepage of the Project Campuskarte
http://campuskarte.tu-berlin.de/
