Pasi Eronen

Implications of Unlicensed Mobile Access (UMA) for GSM security

Despite its imperfections, GSM security has stood well the test of time. In part, this security success has relied on closed platforms that prevent the end-user from tampering with the GSM protocol stacks. While it is possible to build phones that do not have such restrictions, this is difficult due to, e.g., legislation and technical complexity. Unlicensed Mobile Access (UMA) is a new technology that provides access to GSM services over Wireless LAN or Bluetooth. It also challenges the assumption of closed platforms, since it is relatively easy to implement a UMA phone purely in software running on standard PC hardware and operating systems. This paper examines the security implications of UMA for GSM security, focusing especially on the impact of open terminal platforms. We identify several areas where open platforms may increase risks to both honest users and network operators, and propose countermeasures for mitigating these risks.

Authentication components: engineering experiences and guidelines

Security protocols typically employ an authentication phase followed by a protected data exchange. In some cases, such TLS, these two phases are tightly integrated, while in other cases, such as EAP (Extensible Authentication Protocol) and Kerberos, they are separate and often implemented in different endpoints. However, careless application of this separation has lead to several vulnerabilities. In this paper we discuss reasons why this separation is often useful, what mistakes have been made, and what these mistakes have in common. We then describe some approaches how these problems could be avoided, especially focusing on EAP in wireless LANs. We also present some engineering observations that should be taken into account when designing reusable authentication components in the future.

Authentication components: engineering experiences and guidelines (transcript of discussion)

My talk is on authentication components. What I mean by an authentication component is basically a reusable building block. I’m talking about building blocks in a strictly engineering sense (there is very little novel cryptograph use involved), building blocks that are useful to system designers when they’re designing a system and need a protocol for doing something, and they don’t want to reinvent all the cryptographic stuff themselves. Usually they are not experts in that either, so it’s a good thing that they don’t always reinvent things from scratch.