Reducing threats from flawed security APIs: The banking PIN case

Despite best efforts from security API designers, flaws are often found in widely deployed security APIs. Even APIs with a formal proof of security may not guarantee absolute security when used in a real-world device or application. In parallel to spending research efforts to improve security of these APIs, we argue that it may be worthwhile to explore design criteria that would reduce the impact of an API exploit, assuming flaws cannot completely be removed from security APIs. We use such a design philosophy in dealing with PIN cracking attacks on financial PIN processing APIs; several of these attacks have been reported in the last few years, e.g., Berkman and Ostrovsky (FC 2007), Bond (CHES 2001). Our solution is called salted-PIN: a randomly generated salt value of adequate length (e.g., 128 bits) is stored on a bank card in plaintext, and in an encrypted form at a verification facility under a bank-chosen salt key. Instead of sending the regular user PIN, salted-PIN requires an ATM to generate a Transport Final PIN from a user PIN, account number, and the salt value (stored on the bank card) through, e.g., a pseudo-random function. We explore different attacks on this solution, and propose variants of salted-PIN that can protect against known attacks. Depending on the solution variation, attacks at a malicious intermediate switch now may only reveal the Transport Final PIN; both the user PIN and salt value remain beyond the reach of an attacker's switch. Salted-PIN requires modifications to service points (e.g., ATM, point-of-sale), issuer/verification facilities, and bank cards; however, changes to intermediate switches are not required.