Your SlideShare is downloading. ×
0
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Peeter Laud: "Formal Analysis of the Mobile-ID protocol"
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Peeter Laud: "Formal Analysis of the Mobile-ID protocol"

1,122

Published on

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,122
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Analysis of the network security of the Mobile-ID identification protocol Peeter Laud Cybernetica AS & Tartu University
  • 2. The object s A SIM-card that x contains two private keys; x is capable of signing with those keys; x works like an ”‘ordinary”’ SIM-card otherwise. s During its activation SK AS issues certificates that x bind the corresponding public keys to your name; x state that the use of the first key is in identification x . . . and the use of the second key is in signing documents. MoMo, 07.09.2009 – 2 / 14
  • 3. The signing procedure s The card receives (x, M ) from the mobile operator. x x — the (short) message to sign; s a couple of dozen bytes. s might be the hash of the “real” message. x M an explanatory text. x the channel from operator to SIM-card is secure. s The card computes the control code cc(x) of x. x cc(x) ∈ {0000, 0001, 0002, . . . , 9999} s The card shows cc(x) and M to the user (through the phone). s If cc(x) and M OK, the user gives his/her PIN to the card. x Different PIN-s for different keys. s The card verifies PIN, sends sigsk (x) to the operator. MoMo, 07.09.2009 – 3 / 14
  • 4. The identification protocol U C S D O P U S skS skD skU Server’s protected using KP get certS VPN ˜ TLS HS secret Server know certD key U, P TLS HS ˜ S, U, P, r1 User get certU get certU ˜ S, P, r1 r2 ˜ S, r1 r2 CC1 := cc(r1 r2 ) CC2 := cc(r1 r2 ) CC1 CC1 ˜ CC1 S, CC2 ˜ Compare CC1 and CC2 . Check S. sigskU (r1 r2 ) PIN sigskU (r1 r2 ) OK MoMo, 07.09.2009 – 4 / 14
  • 5. The identification protocol U C S D O P U S skS skD skU Phone VPN protected using KP get certS ˜ TLS HS and U, P know certSIM D user’s TLS HS secret ˜ S, U, P, r1 key get certU get certU ˜ S, P, r1 r2 ˜ S, r1 r2 CC1 := cc(r1 r2 ) CC2 := cc(r1 r2 ) CC1 CC1 ˜ CC1 S, CC2 ˜ Compare CC1 and CC2 . Check S. sigskU (r1 r2 ) PIN sigskU (r1 r2 ) OK MoMo, 07.09.2009 – 4 / 14
  • 6. The identification protocol U C S D O P U S skS skD skU protected using KP get certS VPN ˜ TLS HS Client know certD U, P application TLS HS ˜ S, U, P, r1 get certU get certU ˜ S, P, r1 r2 ˜ S, r1 r2 CC1 := cc(r1 r2 ) CC2 := cc(r1 r2 ) CC1 CC1 ˜ CC1 S, CC2 ˜ Compare CC1 and CC2 . Check S. sigskU (r1 r2 ) PIN sigskU (r1 r2 ) OK MoMo, 07.09.2009 – 4 / 14
  • 7. The identification protocol U C S D O P U S skS skD skU protected using KP get certS VPN ˜ TLS HS U, P know certD TLS HS ˜ S, U, P, r1 get certU get certU ˜ S, P, r1 r2 ˜ S, r1 r2 CC1 := cc(r1 r2 ) CC2 := cc(r1 r2 ) CC1 CC1 ˜ CC1 S, CC2 ˜ Compare CC1 and CC2 . Check S. sigskU (r1 r2 ) PIN sigskU (r1 r2 ) OK MoMo, 07.09.2009 – 4 / 14
  • 8. The identification protocol U C S D O P U S skS skD skU protected using KP get certS VPN ˜ TLS HS U, P know certD TLS HS ˜ S, U, P, r1 get certU get certU ˜ S, P, r1 r2 ˜ S, r1 r2 CC1 := cc(r1 r2 ) CC2 := cc(r1 r2 ) CC1 CC1 ˜ CC1 S, CC2 ˜ Compare CC1 and CC2 . Check S. sigskU (r1 r2 ) PIN sigskU (r1 r2 ) OK MoMo, 07.09.2009 – 4 / 14
  • 9. The identification protocol U C S D O P U S skS skD skU protected using KP get certS VPN ˜ TLS HS U, P know certD TLS HS DigiDocService ˜ S, U, P, r1 get certU get certU ˜ S, P, r1 r2 ˜ S, r1 r2 CC1 := cc(r1 r2 ) CC2 := cc(r1 r2 ) CC1 CC1 ˜ CC1 S, CC2 ˜ Compare CC1 and CC2 . Check S. sigskU (r1 r2 ) PIN sigskU (r1 r2 ) OK MoMo, 07.09.2009 – 4 / 14
  • 10. The identification protocol U C S D O P U S skS skD skU protected using KP get certS VPN ˜ TLS HS U, P know certD TLS HS ˜ S = (S, m) ˜ S, U, P, r1 m — a message to be shown get certU get certU on user’s phone screen ˜ S, P, r1 r2 ˜ S, r1 r2 CC1 := 1 —1 a 2 ) r cc(r r random number (10 bytes) CC2 := cc(r1 r2 ) CC1 CC1 ˜ CC1 S, CC2 ˜ Compare CC1 and CC2 . Check S. sigskU (r1 r2 ) PIN sigskU (r1 r2 ) OK MoMo, 07.09.2009 – 4 / 14
  • 11. The identification protocol U C S D O P U S skS skD skU protected using KP get certS VPN ˜ TLS HS U, P know certD TLS HS mobile operator ˜ S, U, P, r1 get certU get certU ˜ S, P, r1 r2 ˜ S, r1 r2 CC1 := cc(r1 r2 ) CC2 := cc(r1 r2 ) CC1 CC1 ˜ CC1 S, CC2 r2 —Compare CC and CC . Check S. a short random number ˜ 1 2 sigskU (r1 r2 ) PIN sigskU (r1 r2 ) OK MoMo, 07.09.2009 – 4 / 14
  • 12. The identification protocol U C S D O P U S skS skD skU protected using KP get certS VPN ˜ TLS HS U, P know certD TLS HS ˜ S, U, P, r1 get certU get certU ˜ S, P, r1 r2 ˜ S, r1 r2 CC1 := cc(r1 r2 ) CC2 := cc(r1 r2 ) CC1 CC1 ˜ CC1 S, CC2 ˜ Compare CC1 and CC2 . Check S. sigskU (r1 r2 ) PIN sigskU (r1 r2 ) OK MoMo, 07.09.2009 – 4 / 14
  • 13. The identification protocol U C S D O P U S skS skD skU protected using KP get certS VPN ˜ TLS HS U, P know certD TLS HS ˜ S, U, P, r1 get certU get certU ˜ S, P, r1 r2 ˜ S, r1 r2 CC1 := cc(r1 r2 ) CC2 := cc(r1 r2 ) CC1 CC1 ˜ CC1 S, CC2 ˜ Compare CC1 and CC2 . Check S. SIM-card computes sigskU (r1 r2 ) PIN sigskU (r1 r2 ) OK MoMo, 07.09.2009 – 4 / 14
  • 14. The identification protocol U C S D O P U S skS skD skU protected using KP get certS VPN ˜ TLS HS U, P know certD TLS HS ˜ S, U, P, r1 get certU get certU ˜ S, P, r1 r2 ˜ S, r1 r2 CC1 := cc(r1 r2 ) CC2 := cc(r1 r2 ) CC1 CC1 ˜ CC1 S, CC2 ˜ Compare CC1 and CC2 . Check S. DigiDocService computes sig (r r ) PIN skU 1 2 sigskU (r1 r2 ) OK MoMo, 07.09.2009 – 4 / 14
  • 15. The identification protocol U C S D O P U S skS skD skU protected using KP get certS VPN ˜ TLS HS U, P know certD TLS HS ˜ S, U, P, r1 get certU get certU ˜ S, P, r1 r2 ˜ S, r1 r2 CC1 := cc(r1 r2 ) CC2 := cc(r1 r2 ) CC1 CC1 ˜ CC1 S, CC2 ˜ Compare CC1 and CC2 . Check S. sigskU (r1 r2 ) PIN sigskU (r1 r2 ) OK MoMo, 07.09.2009 – 4 / 14
  • 16. The identification protocol U C S D O P U S skS skD skU protected using KP get certS VPN ˜ TLS HS U, P know certD TLS HS ˜ S, U, P, r1 get certU get certU ˜ S, P, r1 r2 ˜ S, r1 r2 CC1 := cc(r1 r2 ) CC2 := cc(r1 r2 ) CC1 CC1 ˜ CC1 S, CC2 ˜ Compare CC1 and CC2 . Check S. sigskU (r1 r2 ) PIN sigskU (r1 r2 ) OK MoMo, 07.09.2009 – 4 / 14
  • 17. The identification protocol U C S D O P U S skS skD skU protected using KP get certS VPN ˜ TLS HS U, P know certD TLS HS ˜ S, U, P, r1 get certU get certU ˜ S, P, r1 r2 ˜ S, r1 r2 CC1 := cc(r1 r2 ) CC2 := cc(r1 r2 ) CC1 CC1 ˜ CC1 S, CC2 ˜ Compare CC1 and CC2 . Check S. sigskU (r1 r2 ) PIN sigskU (r1 r2 ) OK MoMo, 07.09.2009 – 4 / 14
  • 18. The identification protocol U C S D O P U S skS skD skU protected using KP get certS VPN ˜ TLS HS U, P know certD TLS HS ˜ S, U, P, r1 get certU get certU ˜ S, P, r1 r2 ˜ S, r1 r2 CC1 := cc(r1 r2 ) CC2 := cc(r1 r2 ) CC1 CC1 ˜ CC1 S, CC2 ˜ Compare CC1 and CC2 . Check S. sigskU (r1 r2 ) PIN sigskU (r1 r2 ) OK MoMo, 07.09.2009 – 4 / 14
  • 19. The identification protocol U C S D O P U S skS skD skU protected using KP get certS VPN ˜ TLS HS U, P know certD TLS HS ˜ S, U, P, r1 get certU get certU ˜ S, P, r1 r2 ˜ S, r1 r2 CC1 := cc(r1 r2 ) CC2 := cc(r1 r2 ) CC1 CC1 ˜ CC1 S, CC2 ˜ Compare CC1 and CC2 . Check S. sigskU (r1 r2 ) PIN sigskU (r1 r2 ) OK MoMo, 07.09.2009 – 4 / 14
  • 20. “Base” security model s There are several users and servers, some under adversarial control. s DigiDocService and mobile operator are honest. x No confusion between different mobile operators. s Client apps. and phones have no malware. x The channels between the user and client app. / phone are secure. s The adversary controls the insecure channels. It can read and write them. s The adversary can take messages apart and construct new messages. It can generate new keys, random numbers, etc. s The adversary can start new sessions. s The adversary schedules all parties. MoMo, 07.09.2009 – 5 / 14
  • 21. Perfect cryptography assumption s Messages have structure x It is their syntax tree. s A message can be analysed only according to its structure: x From (m1 , m2 ) find m1 and m2 . x From enck (m) and k find m. x etc. s To construct a message, we need all of its parts: x Need sk and m to construct sigsk (m). x etc. s Different structure ⇒ different message. x does not apply to control codes. s This is a constraint on the adversary! MoMo, 07.09.2009 – 6 / 14
  • 22. Security properties we care about s If U and S are honest then the TLS key they agreed on will not become known to the adversary. s If S thinks it talks to U using key K and U is honest then U thinks it talks to S using key K. We are protecting an honest server s Integrity for U follows from the properties of TLS handshake. MoMo, 07.09.2009 – 7 / 14
  • 23. Analysing the protocol s We use the perfect cryptography assumption. s The question “does protocol P” satisfy the security property S?” is undecidable in general. s Still, there are tools that take the description of a protocol and output whether it is secure. x Handle restricted classes of protocols. x Sometimes give wrong answer. s Only err at the side of caution. s We have used ProVerif, http://www.proverif.ens.fr s In the base security model the Mobile-ID identification protocol is secure against network attacks. MoMo, 07.09.2009 – 8 / 14
  • 24. Relaxing the security model s DigiDocService and Mobile Operator are just mediating parties. s The security of the protocol should not depend on their honesty. MoMo, 07.09.2009 – 9 / 14
  • 25. A possible scenario U S MoMo, 07.09.2009 – 10 / 14
  • 26. A possible scenario U U S′ S MoMo, 07.09.2009 – 10 / 14
  • 27. A possible scenario U U S′ S U, S ′ , m′ , r1 ′ DDS MoMo, 07.09.2009 – 10 / 14
  • 28. A possible scenario U U S′ S U, S ′ , m′ , r1 ′ U DDS MoMo, 07.09.2009 – 10 / 14
  • 29. A possible scenario U U S′ S U, S ′ , m′ , r1 ′ U U, S, m, r1 DDS MoMo, 07.09.2009 – 10 / 14
  • 30. A possible scenario U U Generate r2 , r2 , such that ′ S′ S cc(r1 r2 ) = c = cc(r1 r2 ) ′ ′ U, S ′ , m′ , r1 ′ U U, S, m, r1 DDS MoMo, 07.09.2009 – 10 / 14
  • 31. A possible scenario U U S ′ , m ′ , r1 r 2 S′ S U, S ′ , m′ , r1 ′ U U, S, m, r1 DDS MO ′ ′ cc(r1 r2 ) = c = cc(r1 r2 ) MoMo, 07.09.2009 – 10 / 14
  • 32. A possible scenario U U S ′ , m ′ , r1 r 2 S′ S c U, S ′ , m′ , r1 ′ U c U, S, m, r1 DDS MO ′ ′ cc(r1 r2 ) = c = cc(r1 r2 ) MoMo, 07.09.2009 – 10 / 14
  • 33. A possible scenario U c U S ′ , m ′ , r1 r 2 S′ S c U, S ′ , m′ , r1 ′ U c U, S, m, r1 DDS MO ′ ′ cc(r1 r2 ) = c = cc(r1 r2 ) MoMo, 07.09.2009 – 10 / 14
  • 34. A possible scenario U c U S ′ , m ′ , r1 r 2 S′ S c U, S ′ , m′ , r1 ′ U c U, S, m, r1 sigskU (r1 r2 ) DDS MO ′ ′ cc(r1 r2 ) = c = cc(r1 r2 ) MoMo, 07.09.2009 – 10 / 14
  • 35. A possible scenario U c U S ′ , m ′ , r1 r 2 S′ S c sigskU (r1 r2 ) U, S ′ , m′ , r1 ′ U c U, S, m, r1 sigskU (r1 r2 ) DDS MO ′ ′ cc(r1 r2 ) = c = cc(r1 r2 ) MoMo, 07.09.2009 – 10 / 14
  • 36. A possible scenario Attack works even if the U server computes the c control code c U S ′ , m ′ , r1 r 2 S′ S c sigskU (r1 r2 ) U, S ′ , m′ , r1 ′ U c U, S, m, r1 sigskU (r1 r2 ) DDS MO ′ ′ cc(r1 r2 ) = c = cc(r1 r2 ) MoMo, 07.09.2009 – 10 / 14
  • 37. Malware in user’s computer s Full control over the client app. means knowing the TLS keys. s Even a keylogger can cause a lot of harm if using the ID-card. s A similar level of control for the mobile-ID protocol might be the control over which control code is shown to the user. s If the display manipulator also has network access then the protocol can be broken. MoMo, 07.09.2009 – 11 / 14
  • 38. A possible scenario U S DDS MoMo, 07.09.2009 – 12 / 14
  • 39. A possible scenario U S DDS MoMo, 07.09.2009 – 12 / 14
  • 40. A possible scenario U S DDS MoMo, 07.09.2009 – 12 / 14
  • 41. A possible scenario U U S U DDS MoMo, 07.09.2009 – 12 / 14
  • 42. A possible scenario U U S U DDS MoMo, 07.09.2009 – 12 / 14
  • 43. A possible scenario U U S U, S, m, r1 ′ U U, S, m, r1 DDS MoMo, 07.09.2009 – 12 / 14
  • 44. A possible scenario U U S U, S, m, r1 c c′ ′ U U, S, m, r1 DDS ′ r 2 , r2 MoMo, 07.09.2009 – 12 / 14
  • 45. A possible scenario U ′ ′ S, m, r1 r2 S, m, r1 r2 U S MO U, S, m, r1 c c′ ′ U U, S, m, r1 DDS ′ r 2 , r2 MoMo, 07.09.2009 – 12 / 14
  • 46. A possible scenario U ′ ′ S, m, r1 r2 c S, m, r1 r2 U S MO U, S, m, r1 c′ c c′ ′ U U, S, m, r1 DDS ′ r 2 , r2 MoMo, 07.09.2009 – 12 / 14
  • 47. A possible scenario c′ U ′ ′ S, m, r1 r2 c S, m, r1 r2 U S MO U, S, m, r1 c′ c c′ ′ U U, S, m, r1 DDS ′ r 2 , r2 MoMo, 07.09.2009 – 12 / 14
  • 48. A possible scenario c′ U ′ ′ sigskU (r1 r2 ) ′ ′ S, m, r1 r2 c S, m, r1 r2 U S MO U, S, m, r1 c′ c c′ ′ U U, S, m, r1 DDS ′ ′ sigskU (r1 r2 ) ′ r 2 , r2 MoMo, 07.09.2009 – 12 / 14
  • 49. Other issues s If the user is duped to connect to a rogue site, then a man-in-the-middle attack is possible. x The attack gives the adversary access to the real site in the name of the user. x This attack is also present when authenticating with passwords (code cards, code calculators, one-time passwords, etc.) x This attack is not present when using the ID-card. s The SIM-card software shows embedded newlines in m as line breaks. x The server can construct a message m that obscures the actual control code. x Not exploitable if the DigiDocService is honest; but must be considered otherwise. MoMo, 07.09.2009 – 13 / 14
  • 50. Suggested changes s Instead of signing the challenge r, sign (r, S). s Whole challenge r should be chosen and the control code CC1 computed by S. x S must avoid control code collsions in parallel sessions with the same U . s Change the way m and CC2 are shown on the phone screen and/or educate users such that CC2 will not be obscured. Still no protection against trojans in phone or computer. MoMo, 07.09.2009 – 14 / 14

×