Why Cryptosystems Fail Prepared by Geoffrey Foote CSC 593 Secure Software Engineering Seminar Spring Semester 2006 Instructors: Dr. Charles Frank Dr. James.

Slides:



Advertisements
Similar presentations
Testing Relational Database
Advertisements

Why Cryptosystems Fail Nick Feamster CS 6262 Spring 2009.
Card Verification Support
Gareth Ellis Senior Solutions Consultant Session 5a Key and PIN Management.
SECURITY IN E-COMMERCE VARNA FREE UNIVERSITY Prof. Teodora Bakardjieva.
Workplace Realities Getting a Job and Getting Ahead.
Chapter 10  ATM 1 Automatic Teller Machines. Chapter 10  ATM 2 Automatic Teller Machines  “…one of the most influential technological innovations of.
Wireless Encryption By: Kara Dolansky Network Management Spring 2009.
Lesson 11-Virtual Private Networks. Overview Define Virtual Private Networks (VPNs). Deploy User VPNs. Deploy Site VPNs. Understand standard VPN techniques.
Chapter 9 Banking and Book keeping Protecting yourself from you.
1 Output Controls Ensure that system output is not lost, misdirected, or corrupted and that privacy is not violated. Exposures of this sort can cause serious.
Chapter 10 Boundary Controls. Cryptographic Controls Cryptology is the science of secret codes Cryptography deals with systems for transforming data into.
Why Cryptosystems Fail?
Why Cryptosystems Fail Ross Anderson Proceeding of the 1 st ACM Conference on Computer and Communications Security, 김학봉.
CMSC 414 Computer and Network Security Lecture 8 Jonathan Katz.
Why cryptosystems Fail Ross Anderson Proceeding of the 1 st ACM Conference on Computer and Communications Security, 1993 SSR Jiyeon Park.
Security Overview. 2 Objectives Understand network security Understand security threat trends and their ramifications Understand the goals of network.
Why Cryptosystems Fail Ross Anderson Presented by Su Zhang 1.
VENDORS, CONSULTANTS AND USERS
Alter – Information Systems 4th ed. © 2002 Prentice Hall 1 E-Business Security.
Introduction to Network Defense
Elements of Internal Controls Preventing Fraud, Waste, and Abuse in Urban and Rural Transit Systems.
By: Dr. Mohammed Alojail College of Computer Sciences & Information Technology 1.
1 Introduction to Security and Cryptology Enterprise Systems DT211 Denis Manley.
Chapter 1 Database Systems. Good decisions require good information derived from raw facts Data is managed most efficiently when stored in a database.
Open Source for Government Alexander C. Pitzner Sr. Network Engineer Harrisburg University of Science and Technology
Will You Ever Use Your ATM Again? Presented by: Bob Clary Carolyn McLellan Jane Mosher Karen Weil-Yates.
SEC835 Database and Web application security Information Security Architecture.
 This presentation looks at: › What is risk management › How to identify risks › How to implement an effective risk management policy to increase your.
The Islamic University of Gaza
Project co-financed by European Union Project co- financed by Asean European Committee for Standardization Implementing Agency 1 Module 13 GMP Workshop.
Information Systems Security Computer System Life Cycle Security.
Update from Business Week Number of Net Fraud Complaints – 2002 – 48,252 – 2004 – 207,449.
 To explain the importance of software configuration management (CM)  To describe key CM activities namely CM planning, change management, version management.
1 Why Cryptosystems Fail Ross Anderson University Computer Laboratory Cambridge
CMSC 414 Computer and Network Security Lecture 2 Jonathan Katz.
The Protection of Information in Computer Systems Part I. Basic Principles of Information Protection Jerome Saltzer & Michael Schroeder Presented by Bert.
Engineering Secure Software. A Ubiquitous Concern  You can make a security mistake at every step of the development lifecycle  Requirements that allow.
I.Information Building & Retrieval Learning Objectives: the process of Information building the responsibilities and interaction of each data managing.
Information Security Antipatterns in Software Requriements Engineering Miroslav Kis Presented by Liping Cai.
Chapter 1 Overview The NIST Computer Security Handbook defines the term Computer Security as:
Computer Security Cryptography. Cryptography Now and Before  In the past – mainly used for confidentiality  Today –Still used for confidentiality –Data.
Copyright 1999 S.D. Personick. All Rights Reserved. Telecommunications Networking II Lecture 41b Cryptography and Its Applications.
Lecture slides prepared for “Computer Security: Principles and Practice”, 3/e, by William Stallings and Lawrie Brown, Chapter 1 “Overview”. © 2016 Pearson.
IT Security Policy: Case Study March 2008 Copyright , All Rights Reserved.
INFORMATION SECURITY MANAGEMENT P ROTECTION M ECHANISMS - C RYPTOGRAPHY.
Database Security Cmpe 226 Fall 2015 By Akanksha Jain Jerry Mengyuan Zheng.
DATA & COMPUTER SECURITY (CSNB414) MODULE 3 MODERN SYMMETRIC ENCRYPTION.
Security Architecture of qmail and Postfix Authors: Munawar Hafiz Ralph E. Johnson Prepared by Geoffrey Foote CSC 593 Secure Software Engineering Seminar.
Software Quality Assurance SOFTWARE DEFECT. Defect Repair Defect Repair is a process of repairing the defective part or replacing it, as needed. For example,
My audience will be excited to learn the basics of what a network systems & data communications analyst does.
Why Cryptosystems Fail R. Anderson, Proceedings of the 1st ACM Conference on Computer and Communications Security, 1993 Reviewed by Yunkyu Sung
CSCI-235 Micro-Computers in Science Privacy & Security.
Network Security Celia Li Computer Science and Engineering York University.
INFORMATION SECURITY MANAGEMENT P ROTECTION M ECHANISMS - C RYPTOGRAPHY.
Learning Intention Security of Information. Why protect files? To prevent unauthorised access to confidential information To prevent virus/corruption.
Extreme programming (XP) Advanced Software Engineering Dr Nuha El-Khalili.
EMV Operation and Attacks Tyler Moore CS7403, University of Tulsa Reading: Anderson Security Engineering, Ch (136—138), (328—343) Papers.
Mar 18, 2003Mårten Trolin1 Agenda Parts that need to be secured Card authentication Key management.
Department of Computer Science Chapter 5 Introduction to Cryptography Semester 1.
 Overview of Project management. ◦ Management. ◦ Project Management. ◦ Software Project Management. ◦ Project(Dimensions, Characteristics, Complexity,
Advanced Software Engineering Dr. Cheng
CS457 Introduction to Information Security Systems
Network Security Presented by: JAISURYA BANERJEA MBA, 2ND Semester.
Why Cryptosystems Fail Ross Anderson University Computer Laboratory
Strategic Human Resource Management
Why Cryptosystems Fail
VENDORS, CONSULTANTS AND USERS
6. Application Software Security
Presentation transcript:

Why Cryptosystems Fail Prepared by Geoffrey Foote CSC 593 Secure Software Engineering Seminar Spring Semester 2006 Instructors: Dr. Charles Frank Dr. James Walden

Overview Cryptology Intro Definitions Case Study: Banking Industry and ATM Fraud Fraud Types Insider Knowledge and Access Outside Attacks with Minimal Technical Knowledge Banks without Security Modules Inferior Security Products Poor Implementation and/or Sloppy Operating Procedures

Cont. Overview Consequences for Bankers Implications for Equipment vendors Why the Threat Model was Wrong??? Authors Confirmation of this Shift to New Security Paradigm??? Conclusions/Discussion

Cryptology Intro Main User of Cryptosystems Government Agencies NSA Generally do not release failure reports Puts Cryptographic Designers at a severe disadvantage Removes Learning Mechanism

Cryptology Intro Since Government Agencies are very secretive about their mistakes We must look elsewhere for examples Next largest application of Cryptology Retail Banking Systems Therefore we’ll take a look their failure modes

Relevant Definitions Cryptology – the science of code and cipher systems Cryptography – converting info from its normal form to an unreadable form without access to a key Cryptanalysis – code breaking, accessing encrypted info without secret key Cryptosystems – package of all procedures, protocols and algorithms used for enciphering and deciphering messages using cryptography

Case Study: ATM Fraud Inside Knowledge or Access Bank Stat Bank teller/clerk issue extra card Maintenance Engineer retrofitted an ATM with a mini PC to record account numbers and PIN’s Then produced counterfeit cards Dual Control of cards and pins dropped to cut costs

Case Study: ATM Fraud Outsider Attacks Simple yet Effective: Observing customers entering PIN’s and pick up discarded receipts Another Example – telephone card Jackpotting ATM networks do not encrypt/authenticate the authorization response to the ATM Attacker can then record a ‘pay’ response and replay it until the ATM is empty

Case Study: ATM Fraud Outsider Attacks Postal Interception Similar to Credit Cards Test Transactions in ATM’s Implementation error, sequence printed in branch manual False Terminals Harvest account numbers and PIN’s from unknowing customers

Case Study: ATM Fraud Outsider Attacks PIN Security Reductions PIN’s checked and set by offline devices Devices do not always use full encryption Insecure bank suggestions Random letter card Reduced chances of guessing PIN from 1 in 3,333 to 1 in 8 Using default PIN numbers Result of a simple programming error

Case Study: ATM Fraud Outsider Attacks PIN’s not derived from account number Encrypted PIN’s on a file Programmer could look for other accounts with the same encrypted PIN as their own Encrypted PIN’s written to the card stripe Thief could then change the account number of their card and access and other account using their PIN

Case Study: ATM Fraud How ATM Encryption Works Account Number: PIN Key: GGFFGGFFFGGF Result of DES: R2FF3Y2430TG Result decimalized: Natural PIN: 0777 Offset: 1111 Customer PIN: 1888

Case Study: ATM Fraud Problems with encryption products Banks without Security Modules Encryption is then handled in SW Biggest problem is that the PIN key can easily be found by system programmers Even if security is added at a later date is unlikely to fix the problem PIN key is so valuable to networked ATM’s that knowledge will likely remain among programming staff

Case Study: ATM Fraud Inferior Security Products Backdoors in security module’s SW Security modules enclosures could be comprised Often possible to penetrated by drilling or cutting Tamper protection implemented with wires leading to switches Maintenance engineer could easily cut, then have access to keys on next visit

Case Study: ATM Fraud Poor Implementation or Operating Procedures Ignoring response codes ‘Key Parity Error’ programmer altering live module Giving the PIN key to a facilities management firm Employee turnover Outside firms may not share banks security culture

Case Study: ATM Fraud Poor Implementation or Operating Procedures Poor Design Psychology Banks end up cutting corners and share sensitive information “Security by Obscurity” often does more harm than good Not properly incorporated in operational procedures Should be explicitly stated in all manuals and training courses

Case Study: ATM Fraud Cryptanalysis Banks using weak Encryption Algorithms Home-grown algorithms Pre-DES algorithms Respectable Algorithm poorly implemented Using a key that is too small to provide the necessary security Writing the PIN to the card track DES Keys can be found by brute force Once found all PINs could be decrypted Countries in chaos have proper equipment

Consequences for Bankers Original goal of ATM crypto security No system fraud could take place without at least two bank staff Why has this not happened? Poor Implementation Unorganized and Uniformed Administration Higher emphasis on Quality Control

Consequences for Bankers Concerns for the Future Current Security Systems Built from components that were not well understood Admin support requirements not clearly defined These current issues will slow transition Making it harder to integrate new components Decreasing the likelihood of proper long term maintenance

Implications for Equipment Vendors Re-evaluate the system level approach to designing and evaluating security What should they design towards? Autonomous Systems Modifiable Systems that require proper administration and maintenance Develop a Certification Process to address the human environment that the system will operate in

Implications for Equipment Vendors Three courses of Action Designs systems that can be easily integrated and maintained by a general computer staff Train and certify client personnel to perform integration and maintenance Provide their own personnel to implement, support and manage the system **The ideal/actual solution will probably be some combination of the three

Why the Threat Model was Wrong? Two Major Reasons Threat was misjudged Expected criminals with a high level of technical expertise Customers’ Abilities severely Misjudged Assumed the implementers at customer sites would have the appropriate expertise for the job Or that they would enlist the help of quality consulting to complete the task

Why the Threat Model was Wrong? Why were the Threat and Customer Abilities so badly misjudged? Companies imported help from the military sector The military model strictly focused on security Human factors Many organizations security teams were nonexistent or limited Some Consulting firms miss represent their technical expertise in the area of computer security

Confirmation of this Analysis The military sector has had the exact same experiences: Specifically reported by an senior NSA scientist The vast majority of failures are occurring at the level of implementation The NSA is not more clever than the civilian population, just better informed The threat profiles developed by the NSA for its own use are classified

Shift to New Security Paradigm??? Author believes this report provides evidence that a shift is necessary Shift from building evaluated products to focusing on quality control products within the client organization Author suggests a metaphor to safety critical systems Competing Philosophies Railway Signaling Systems vs. Aviation Paradigm

Conclusions / Discussion Why Have Cryptosystems been Failing? Cryptosystems designers have a lack of feedback on how there systems fail Therefore they’ve been designing towards the wrong end Many security products are so complex and tricky to use the are rarely used properly As a result most security failures are due to implementation and management errors

Conclusions / Discussion Certification Remain focused at the component level? Shift focus more towards environments? Specifically Where the systems will be used Human Factors Security Process Automate It? Enable it to be Managed? Questions / Comments ???