A User Centric Security Model for Tamper-Resistant Devices

More documents

Recommendations

Info

6.6 Analysis of the Proposed Protocols The CasperFDR tool evaluated the protocols and did not nd any feasible attack(s). 6.6.3 Revisiting the Requirements and Goals In this section, we take the security goals and requirements stipulated in section 6.2.3 and provide a comparison of the proposed protocols with the selected protocols 6.2.2. As shown in the table 6.2, the STS protocol meets the rst 11 goals along with goal 15. The remaining goals are not met by the STS because of the design architecture and the deployment environment, which did not require these goals. Similarly, the AD protocol does not meet goals 6, 10 and 1319. In the AD protocol, the user reveals her identity by sending the user certicate as plaintext along with the no mutual key conrmation. The most promising results were from the ASPeCT and JFK protocols that meet a large set of goals. Both of these protocols can be easily modied to provide the trust assurance (requiring additional signature). However, both of these protocols are vulnerable to partial chosen key attacks, but in the table 7.3 we opt for the possibility that the JFK can be modied to overcome this problem. The reason behind this is based on the entity that takes the initiator's role. Therefore, if in the JFK we opt for the assumption that an SP will always take the initiator's role then this goal is met by the JKF. The T2LS protocol meets the trust assurance goal by default. However, because it is based on the TLS protocol, which does not meet most of the requirements of the STCP, the T2LS also does not meet them. A note in favour of the SCP81, MM, and SM protocols is that they were designed with the assumption that an application provider has a prior trusted relationship with the smart card issuer; thus, they implicitly trust the respective smart card. This assumption, which is fundamentally incompatible with the UCOM, is why these protocols fail to support a large number of the listed goals. Most of these protocols to some extent have an architecture similar to the one with which a server generates the key and then communicates that key to the client (i.e. read smart card). They do not provide non-repudiation because they do not use signatures in the protocol run. Nevertheless, the proposed STCP ACA protocol meets all the listed goals. Table 6.2 provides a comparison between the listed protocols in section 6.2.2 with the proposed protocols under the required goals (see section 6.2.3). In table 6.2, we show that STCP SC does not meet the goal 17 beside the fact that SPs in STCP SC does not require user identication. Therefore, a malicious user can install an application that does not belong to him. On the other hand, if the SP does require the user's identication during the application personalisation (after the application is installed) then the personalisation process [10] should take into account the platform & 152
6.6 Analysis of the Proposed Protocols SOG Table 6.2: Protocol comparison based on the stated goals (see section 6.2.3) Protocols STS AD ASPeCT JFK T2LS SCP81 MM SM STCP SP STCP SC STCP ACA 1. Mutual Entity Authentication ∗ ∗ ∗ ∗ ∗ ∗ −∗ −∗ ∗ ∗ ∗ 2. Exchange Certicates ∗ ∗ ∗ ∗ ∗ ∗ ∗ −∗ ∗ ∗ ∗ 3. Mutual Key Agreement ∗ ∗ ∗ ∗ ∗ ∗ ∗ −∗ ∗ ∗ ∗ 4. Joint Key Control ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ 5. Key Freshness ∗ ∗ ∗ ∗ ∗ ∗ ∗ −∗ ∗ ∗ ∗ 6. Mutual Key Conrmation ∗ ∗ ∗ ∗ −∗ ∗ ∗ ∗ 7. Known-Key Security ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ 8. Unknown Key Share Resilience ∗ ∗ ∗ ∗ ∗ ∗ ∗ −∗ ∗ ∗ ∗ 9. KCI Resilience ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ 10. Perfect Forward Secrecy ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ 11. Mutual Non-Repudiation ∗ (∗) +∗ ∗ ∗ ∗ +∗ +∗ ∗ ∗ ∗ 12. PCK Attack Resilience (∗) (∗) (∗) (∗) (∗) ∗ ∗ ∗ 13. Trust Assurance ∗ −∗ ∗ ∗ ∗ 14. DoS Prevention ∗ ∗ ∗ ∗ 15. Privacy (∗) ∗ ∗ ∗ ∗ ∗ 16. Simulator Attack Resilience −∗ ∗ ∗ ∗ 17. PAU Attack Resilience ∗ ∗ 18. Contractual Agreement +∗ +∗ ∗ 19. Proof of Transaction ∗ +∗ +∗ +∗ +∗ +∗ +∗ ∗∗ Note: ∗ means that the protocol meets the stated goal, ∗∗ indicates that the protocol meets the SOG if required by the communicating entities, (∗) shows that the protocol can be modied to satisfy the requirement, +∗ shows that protocol can meet the stated goal but requires an additional pass or extra signature generation, and −∗ means that the protocol (implicitly) meets the requirement not because of the protocol messages but because of the prior relationship between the communicating entities. 153
Page 1 and 2:
A User Centric Security Model for T
Page 3 and 4:
Declaration These doctoral studies
Page 5 and 6:
R. N. Akram, K. Markantonakis, and
Page 7 and 8:
Abstract In this thesis we propose
Page 9 and 10:
CONTENTS 3.4.1 Supplier . . . . . .
Page 11 and 12:
CONTENTS 7 Application Sharing Mech
Page 13 and 14:
CONTENTS C.4 Secure and Trusted Cha
Page 15 and 16:
LIST OF FIGURES 8.6 Control ow diag
Page 17 and 18:
List of Abbreviations AAC Applicati
Page 19 and 20:
1.1 Setting the Scene 1.1 Setting t
Page 21 and 22:
1.2 A Brief History of Smart Cards
Page 23 and 24:
1.3 Motivation and Challenges Over
Page 25 and 26:
1.3 Motivation and Challenges compu
Page 27 and 28:
1.4 Contributions the UCTD manufact
Page 29 and 30:
1.5 Structure of the Thesis traditi
Page 31 and 32:
Chapter 2 User Centric Tamper-Resis
Page 33 and 34:
2.2 Rationale for a User Centric Ta
Page 35 and 36:
2.2 Rationale for a User Centric Ta
Page 37 and 38:
2.3 Candidates for User Centric Tam
Page 39 and 40:
Page 41 and 42:
Page 43 and 44:
Businesses Governments Privacy Pres
Page 45 and 46:
2.4 The User Centric Tamper-Resista
Page 47 and 48:
2.5 Case Studies an enrolment proce
Page 49 and 50:
2.5 Case Studies issued the applica
Page 51 and 52:
Chapter 3 Smart Card Ownership Mode
Page 53 and 54:
3.2 Issuer Centric Smart Card Owner
Page 55 and 56:
3.2 Issuer Centric Smart Card Owner
Page 57 and 58:
3.3 Frameworks for the ICOM which i
Page 59 and 60:
3.3 Frameworks for the ICOM Applica
Page 61 and 62:
3.3 Frameworks for the ICOM which i
Page 63 and 64:
3.3 Frameworks for the ICOM Element
Page 65 and 66:
3.4 User Centric Smart Card Ownersh
Page 67 and 68:
Page 69 and 70:
Page 71 and 72:
3.5 Security and Operational Requir
Page 73 and 74:
Page 75 and 76:
Page 77 and 78:
Service Provider 3.6 Coopetitive Ar
Page 79 and 80:
Chapter 4 User Centric Smart Card A
Page 81 and 82:
4.2 Platform Architecture Platform
Page 83 and 84:
4.2 Platform Architecture manager c
Page 85 and 86:
4.3 Trusted Environment & Execution
Page 87 and 88:
Page 89 and 90:
Page 91 and 92:
4.4 Security Assurance and Validati
Page 93 and 94:
4.5 Attestation Mechanisms 4.5 Atte
Page 95 and 96:
4.5 Attestation Mechanisms rational
Page 97 and 98:
4.5 Attestation Mechanisms otherwis
Page 99 and 100:
4.6 Device Ownership 4.6.2 User Own
Page 101 and 102: 4.7 Attestation Protocol can succes
Page 103 and 104: 4.7 Attestation Protocol an adversa
Page 105 and 106: 4.7 Attestation Protocol SC i ′ a
Page 107 and 108: 4.8 Protocol Analysis CasperFDR app
Page 109 and 110: 4.9 Summary whereas the online atte
Page 111 and 112: 5.1 Introduction 5.1 Introduction E
Page 113 and 114: 5.2 GlobalPlatform Card Management
Page 115 and 116: 5.3 Multos Card Management Framewor
Page 117 and 118: 5.4 Proposed Smart Card Management
Page 119 and 120: 5.4 Proposed Smart Card Management
Page 121 and 122: 5.5 Card Management-Related Issues
Page 127 and 128: Chapter 6 Secure and Trusted Channe
Page 129 and 130: 6.2 Secure Channel Protocols 6.2 Se
Page 131 and 132: 6.2 Secure Channel Protocols smart
Page 133 and 134: 6.2 Secure Channel Protocols SOG-16
Page 135 and 136: 6.2 Secure Channel Protocols Notati
Page 137 and 138: 6.3 Secure and Trusted Channel Prot
Page 139 and 140: 6.4 Secure and Trusted Channel Prot
Page 141 and 142: 6.5 Application Acquisition and Con
Page 147 and 148: 6.6 Analysis of the Proposed Protoc
Page 151: 6.6 Analysis of the Proposed Protoc
Page 155 and 156: 6.7 Summary For the STCP ACA , we n
Page 157 and 158: Chapter 7 Application Sharing Mecha
Page 159 and 160: 7.2 Application Sharing Mechanism 7
Page 161 and 162: 7.2 Application Sharing Mechanism I
Page 163 and 164: 7.2 Application Sharing Mechanism a
Page 165 and 166: 7.3 UCTD Firewall utilises CDAM to
Page 167 and 168: 7.3 UCTD Firewall application. Ther
Page 169 and 170: 7.3 UCTD Firewall 7.3.6 Cross-Devic
Page 171 and 172: 7.3 UCTD Firewall and asynchronous
Page 173 and 174: 7.3 UCTD Firewall Table 7.2: Protoc
Page 175 and 176: 7.4 Application Binding Protocol L
Page 177 and 178: 7.5 Platform Binding Protocol The r
Page 179 and 180: 7.6 Application Binding Protocol D
Page 187 and 188: Chapter 8 Smart Card Runtime Enviro
Page 189 and 190: 8.2 Smart Card Runtime Environment
Page 195 and 196: 8.3 Runtime Protection Mechanism In
Page 197 and 198: 8.3 Runtime Protection Mechanism it
Page 199 and 200: 8.3 Runtime Protection Mechanism er
Page 201 and 202: 8.3 Runtime Protection Mechanism id
Page 203 and 204:
8.3 Runtime Protection Mechanism Th
Page 205 and 206:
8.4 Analysis of the Runtime Protect
Page 207 and 208:
8.4 Analysis of the Runtime Protect
Page 209 and 210:
8.5 Summary representation; the abs
Page 211 and 212:
Chapter 9 Backup, Migration, and De
Page 213 and 214:
9.2 Backup and Migration Framework
Page 215 and 216:
9.2 Backup and Migration Framework
Page 217 and 218:
9.3 Application Deletion tion of th
Page 219 and 220:
9.3 Application Deletion The deleti
Page 221 and 222:
9.3 Application Deletion authorises
Page 223 and 224:
9.5 Summary 9.5 Summary In this cha
Page 225 and 226:
10.1 Summary and Conclusions 10.1 S
Page 227 and 228:
10.1 Summary and Conclusions giving
Page 229 and 230:
10.2 Recommendations for Future Wor
Page 231 and 232:
Appendix A Description of Protocols
Page 233 and 234:
A.3 Aziz-Die (AD) Protocol on the p
Page 235 and 236:
A.5 Just-Fast-Keying (JFK) Protocol
Page 237 and 238:
A.8 Markantonakis-Mayes (MM) Protoc
Page 239 and 240:
A.9 Sirett-Mayes-Markantonakis (SM)
Page 241 and 242:
B.1 Brief Introduction to the Caspe
Page 243 and 244:
B.3 Secure and Trusted Channel Prot
Page 245 and 246:
B.4 Secure and Trusted Channel Prot
Page 247 and 248:
B.6 Application Binding Protocol L
Page 249 and 250:
B.7 Platform Binding Protocol B.7 P
Page 251 and 252:
B.8 Application Binding Protocol D
Page 253 and 254:
C.1 Oine Attestation Mechanism C.1
Page 255 and 256:
C.1 Oine Attestation Mechanism 93 (
Page 257 and 258:
C.1 Oine Attestation Mechanism 194
Page 259 and 260:
C.1 Oine Attestation Mechanism 47 (
Page 261 and 262:
C.1 Oine Attestation Mechanism 148
Page 263 and 264:
C.2 Online Attestation Mechanism C.
Page 265 and 266:
C.2 Online Attestation Mechanism 10
Page 267 and 268:
Page 269 and 270:
Page 271 and 272:
Page 273 and 274:
C.3 Attestation Protocol 15 import
Page 275 and 276:
C.3 Attestation Protocol 112 f a l
Page 277 and 278:
C.3 Attestation Protocol 214 } 215
Page 279 and 280:
C.3 Attestation Protocol 312 inLeng
Page 281 and 282:
C.3 Attestation Protocol 410 this .
Page 283 and 284:
C.3 Attestation Protocol 7 import j
Page 285 and 286:
C.3 Attestation Protocol 107 this .
Page 287 and 288:
C.3 Attestation Protocol 204 ( this
Page 289 and 290:
C.3 Attestation Protocol 302 } 303
Page 291 and 292:
C.4 Secure and Trusted Channel Prot
Page 293 and 294:
Page 295 and 296:
Page 297 and 298:
Page 299 and 300:
Page 301 and 302:
Page 303 and 304:
Page 305 and 306:
Page 307 and 308:
Page 309 and 310:
Page 311 and 312:
Page 313 and 314:
Page 315 and 316:
Page 317 and 318:
Page 319 and 320:
Page 321 and 322:
Page 323 and 324:
Page 325 and 326:
Page 327 and 328:
Page 329 and 330:
Page 331 and 332:
Page 333 and 334:
C.6 Application Acquisition and Con
Page 335 and 336:
Page 337 and 338:
Page 339 and 340:
Page 341 and 342:
Page 343 and 344:
Page 345 and 346:
Page 347 and 348:
Page 349 and 350:
Page 351 and 352:
Page 353 and 354:
Page 355 and 356:
Page 357 and 358:
Page 359 and 360:
Page 361 and 362:
Page 363 and 364:
Page 365 and 366:
C.7 Application Binding Protocol -
Page 367 and 368:
Page 369 and 370:
Page 371 and 372:
Page 373 and 374:
Page 375 and 376:
Page 377 and 378:
Page 379 and 380:
Page 381 and 382:
Page 383 and 384:
Page 385 and 386:
Page 387 and 388:
Page 389 and 390:
Page 391 and 392:
Page 393 and 394:
Page 395 and 396:
Page 397 and 398:
Page 399 and 400:
Page 401 and 402:
Page 403 and 404:
Page 405 and 406:
C.9 Platform Binding Protocol 17 im
Page 407 and 408:
C.9 Platform Binding Protocol 119 p
Page 409 and 410:
C.9 Platform Binding Protocol 221 i
Page 411 and 412:
C.9 Platform Binding Protocol 323 c
Page 413 and 414:
C.9 Platform Binding Protocol 424 +
Page 415 and 416:
C.9 Platform Binding Protocol 524 S
Page 417 and 418:
Page 419 and 420:
C.9 Platform Binding Protocol 47 (
Page 421 and 422:
C.9 Platform Binding Protocol 149 J
Page 423 and 424:
Page 425 and 426:
C.9 Platform Binding Protocol 350 +
Page 427 and 428:
C.9 Platform Binding Protocol 451 p
Page 429 and 430:
C.9 Platform Binding Protocol 552 r
Page 431 and 432:
C.10 Abstract Virtual Machine 42 "
Page 433 and 434:
C.11 Implementation Helper Classes
Page 435 and 436:
Page 437 and 438:
Page 439 and 440:
Page 441 and 442:
Page 443 and 444:
Page 445 and 446:
Page 447 and 448:
Page 449 and 450:
Page 451 and 452:
BIBLIOGRAPHY August 2009, pp. 2035.
Page 453 and 454:
BIBLIOGRAPHY Available: http://www.
Page 455 and 456:
BIBLIOGRAPHY Institute of Technolog
Page 457 and 458:
BIBLIOGRAPHY ing, vol. 2, pp. 42342
Page 459 and 460:
BIBLIOGRAPHY Available: http://csrc
Page 461 and 462:
BIBLIOGRAPHY Group_TRUST/PubsPDF/CA
Page 463 and 464:
BIBLIOGRAPHY [161] D. A. Basin, S.
Page 465 and 466:
BIBLIOGRAPHY pp. 1414. [186] R. N.
Page 467 and 468:
BIBLIOGRAPHY [208] T. S. Messerges,
Page 469:
BIBLIOGRAPHY Science, P. Samarati,
show all

A User Centric Security Model for Tamper-Resistant Devices

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?