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

Analysis of the network security of the Mobile-ID identiﬁcation protocol Peeter Laud Cybernetica AS & Tartu University

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

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

The identiﬁcation 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

The identiﬁcation 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

The identiﬁcation 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

The identiﬁcation 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

The identiﬁcation 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

The identiﬁcation 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

The identiﬁcation 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

The identiﬁcation 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

The identiﬁcation 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

“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 diﬀerent 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

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

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

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 identiﬁcation protocol is secure against network attacks. MoMo, 07.09.2009 – 8 / 14

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

A possible scenario U S MoMo, 07.09.2009 – 10 / 14

A possible scenario U U S′ S MoMo, 07.09.2009 – 10 / 14

A possible scenario U U S′ S U, S ′ , m′ , r1 ′ DDS MoMo, 07.09.2009 – 10 / 14

A possible scenario U U S′ S U, S ′ , m′ , r1 ′ U DDS MoMo, 07.09.2009 – 10 / 14

A possible scenario U U S′ S U, S ′ , m′ , r1 ′ U U, S, m, r1 DDS MoMo, 07.09.2009 – 10 / 14

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

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

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

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

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

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

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

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

A possible scenario U S DDS MoMo, 07.09.2009 – 12 / 14

A possible scenario U U S U DDS MoMo, 07.09.2009 – 12 / 14

A possible scenario U U S U, S, m, r1 ′ U U, S, m, r1 DDS MoMo, 07.09.2009 – 12 / 14

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

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

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

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

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

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

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

http://www.momoestonia.com	29
http://www.mobilemonday.net	8
http://www.slideshare.net	1

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

by Mobile Monday Estonia on Sep 17, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

3 Embeds 38

Statistics

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