T Salausjärjestelmät (Cryptosystems) Introduction to the second part of the course. Outline. What we'll cover. Requirements and design issues

Transcription

1 T Salausjärjestelmät (Cryptosystems) Requirements and design issues Introduction to the second part of the course Outline What we'll cover Introduction to the second part of the course Requirements and design issues Threats, security models, assumptions Risk analysis Choosing a cryptosystem Common design principles Assurance and evaluation We'll look at cryptosystem implementation For a large part just implementing secure (correct) software There are cryptography specific challenges and methods, though We'll look at both kinds of techniques Motivation: implementation is often the weakest link Much less organized than cryptography theory We'll use the software life cycle for structure There are models for the design process But for practical implementation, there is less structure Although a bit messy, these are important issues Importance of software security is increasing Security can be cost-efficient (e.g. savings in updates, complaints,...) 2 4

2 Security and functionality are very different Some problems The attacker always has the advantage You need to cover all the holes; the attacker needs to find one hole Security is invisible You can't read it off a product label You can't directly measure it, like functionality Security failures are difficult to notice Security failures are often silent Example: encryption keys are not derived correctly E.g. IPsec implementation initializes key to zero and only initializes the first byte of the key correctly => 256 possible keys Example: cryptographic keys are accidentally leaked to hard drive Catastrophic for a hard disk encryption system => Importance of standards, interop testing with independent code, test vectors, etc. 5 We can't specify everything in practice There are common expectations for secure software Example: if result of function is undefined on some input, we still expect it to maintain security (not to leak keys or format hard drive) Some of these are captured by common design principles Secure is relative to something, e.g. to a threat model It does not mean there are no successful exploits Example: physical tampering attack not in software scope Example: RSA is always breakable Secure is often subjective Example: estimating the expected monetary impact of an attack What is the probability of an attack? What is the probability of success, if an attack occurs? These are subjective probabilities 7 What is a secure implementation? What keeps us from getting the implementation right? There are (at least) two broad concepts of security 1) The program is free of flaws 2) The program may have flaws, but they are not exploitable The second concept is what we use today Penetrate and patch model of development Defense in depth, multiple overlapping mechanisms Damage control if a flaw is found to prevent actual exploits A pessimistic view there will be flaws, you just have to manage them Requires continuous software updates The first concept is more or less theoretical We don't need defense-in-depth if we operate in this model It's not an impossible model, we just don't have the tools yet to make it practical 6 Most of the world is focused on functionality not security These two are conceptually very different Programming languages and tools are not always suitable Unsafe programming languages (e.g. C) widely used Safe (type safe) programming languages Corporate pressure The release deadline is coming up, and the software works... mostly Security is not productive for a manager Ideally security testing is a waste of time! That is, the software is free of flaws, and we don't find any But if we don't test, we just don't know... 8

3 Life cycle model Basic design issues Requirements Verify Verify Design Refine Refine Implementation Testing Deployment Main software development 1. Develop correct requirements 2. Refine progressively 3. Verify that each refinement is correct (NB: Testing is really just verification of implementation, but we depict it separately as is usually done.) Threat model and threat tree Identifying your assets Developing a threat model Risk analysis, cost-benefit analysis Security objectives and assumptions Security functions Considerations for cryptosystem selection Software maintenance 1. Diagnose problem 2. Escalate to appropriate level 3. Incremental fix and verification 4. Deployment of fix Maintenance Retirement 9 11 Security and safety compared Safety Security Safety mechanism Safety risk Security mechanism Security risk Requirements and design issues Hazard Threat Accident Attack Attacker Vulnerability Harm Vulnerability Harm Asset Asset 10 12

4 Threat model Security is always relative to threats Without a model of threats, it's difficult to define what security means Threats are related to assets under protection (e.g. information) Defining the threat model is a good starting point Define the threats for the system exhaustively (try to) Start with general categories and refine them further Describe attackers and their capabilities The set of threats is infinite, but we must still try It's difficult to ensure a design is secure unless we know what sorts of threats we're working against Working on threat scenarios inspires better design Also rule out categories we're not interested in For instance, physical tampering, electromagnetic attacks in case of networked software 13 Risk analysis Threats can be quantified using risk analysis Model 1 Expected damage = Prob( Attack succeeds ) * Average impact Compare value of asset with expected damage Model 2 Estimate monetary resources required to damage assets Compare estimated cost to estimated damage We can then make more informed decisions on security I.e. which threats we consider to be out of scope Notes about risks 1. Risk is a function of environment 2. Risks change with time (e.g. changes in environment, new technology) 3. Risks are often very remote, but still need to be considered 15 Threat tree Security objectives and assumptions Threat tree Root = all threats, children are main categories of threats Nodes are further subdivided to more and more refined threats Each level should be complete, i.e. cover all threats covered by parent Often an and-or structure is used (notation varies) A part of threat model T t 1 t 2 t 3 by (t 1 and t 2 ) or t 3 Parent threat T is caused (only) Each threat is covered by a) stating that it is out of scope (=> described in assumptions) b) describing required security objective(s) which address the threat c) a combination of a) and b) Security objective A high level requirement, refined to security function(s) in design Assumption Example: It is assumed that access to the physical hosts used in the system is restricted to trusted personnel Example Threat: unauthorized access to resources Security objective: require user identification and authentication before a user is given access to resources Assumption: only network access is possible, physical access is protected 16

5 Security functions Choosing a cryptosystem More concrete than security objectives E.g. cryptographic protocols and primitives Must address all security objectives satisfactorily And ultimately, the threat model Example: Threat model: passive eavesdroppers on communication line Security objective: encryption for communication Security function: anonymous TLS using ciphersuite X Layer in networking stack affects choice, examples Bulk encryption (point-to-point) IPsec or other per-packet system Application data (point-to-point) TLS or other stream-based system Content (or relay protocol) PGP or other object-security system Underlying layers are also your problem E.g. if you send PGP data over TCP, protection against Denial-of-Service is more difficult Process and environment issues Cryptosystems require a supporting environment (physical, processes,...) Key management is often problematic, e.g. for PKIs a huge deployment issue User password management, dealing with lost passwords, etc. If you don't take processes into accounts, your effort may backfire Typical example: too complex passwords => people write them down Choosing a cryptosystem Dolev-Yao model is often good for networking An attacker can obtain any message passing through the network; is a legitimate user of the network, and thus in particular can initiate a conversation with any other user; will have the opportunity to be a receiver to any principal; can send messages to any principal by impersonating any other principal. In other words: the attacker carries your messages Network may often be considered only point of access Assumption of physical security, assume no backdoors E.g. login using SSH, use broken permissions to add trusted Choosing a cryptosystem You should use an existing cryptosystem / protocol Designing a cryptosystem is very difficult Even if you get it right, you'll have to convince others The gains of your own design are likely to be quite small You can use a profile of an existing cryptosystem For instance: select a subset of crypto algorithms, fix key lengths, don't support optional functional features, etc. You can even drop mandatory features if necessary, as long as you don't touch security critical components Example: Our HTTPS client is a non-compliant subset, but interoperates certificates Thus we're mostly interested in attacker computation capabilities, strengths of cryptosystems (in the mathematical sense) Affects key length decisions, for instance 18 20

6 Choosing a cryptosystem Some terminology from access control Library support If based on a standard, existing cryptosystems may have partial support Performance and code/data size Sometimes cannot be overlooked, but less and less relevant Code/data size can be minimized by e.g. Decreasing number of supported algorithms Selecting algorithms with small footprint Specialized implementation for small size or performance Asymmetric algorithms often use dynamic memory management, which may be a problem Can be avoided by fixing big number sizes (key lengths) Symmetric algorithms vary greatly in resource requirements Subject E.g. a user, a UNIX process,... Object E.g. a file, a UNIX process,... Operation E.g. read, write, delete, execute,... Right (privilege) Privilege: Operation X on object Y is allowed for subject Z Two basic models Access Control Lists (ACLs): (Subject, Operation) tuples per object Capabilities: (Object, Operation) tuples owned by process Common design principles Least privilege A subject should only have the minimum privileges it needs to Common design principles (Mostly based on Matt Bishop: Computer Security: Art and Science) complete its task Within reason: the administration of exact privileges must not complicate system to offset the benefits This is basically a principle of containment the impact of an attack is contained if least privileges are used Fail-safe defaults The system should default to deny in access control E.g. if a new subject is created, it should have no rights except those explicitly given 22 24

7 Common design principles Common design principles Economy of mechanisms (KISS) Mechanisms for implementing security should be as simple as possible Applies to design, implementation of modules, module interfaces, etc.!"# Complete mediation All accesses to objects should be checked Essentially, caching is considered bad UNIX: open() checks for privileges, but an open file descriptor can be used even if the privileges are later revoked Check return code of all functions and system calls Check that the action was actually taken (don't trust the OS) E.g. change uid => check return code, and then check using getuid Least common mechanism Mechanisms used to access resources should not be shared If resources are shared, a transmission channel may be inadvertently formed, leaking information Psychological acceptance Security mechanisms should not make a resource more difficult to access than without the security mechanisms Unachievable in practice, so we need to compromise Example: when using username/password authentication, we don't usually indicate which one was incorrect; however, this makes usage more difficult Without psychological acceptance, people work around systems, possibly decreasing overall security Common design principles More design principles... Open design $Security of a system should not depend on the secrecy of its design or implementation $Compare to Kerckhoffs' principle in cryptography $Current commercial software does not follow this principle $Controversial %Dedicated attacker: can steal secrets, and get source code anyway %Casual attacker: it's easier to attack if you've got the source Separation of privilege $Permission should not be granted based on a single condition $Essentially Defense in depth Trusted computing base (TCB) TCB = software and hardware that implement the system's information security policies Kernel, trusted system processes, configuration files, etc. Security of TCB depends on... Correct requirements, design, and implementation Protection of TCB mechanisms Correct inputs (e.g. security policies) Example: VPN gateway Packet processing is part of the TCB; security policy for traffic However, security of TCB!= security of system Firewall / VPN is trusted, and designed accordingly A user space process can still get malicious inputs because the TCB 26 does not inspect traffic 28

8 Assurance and trust Assurance and evaluation Trust through evaluation A system is considered trusted if it has been shown to meet requirements under an evaluation by certified experts Note that trust and security are different concepts A non-trusted system may be secure (just not evaluated to be secure) A trusted system (evaluated) may be insecure But we hope that evaluation correlates with overall security Evaluation provides assurance Correspondence between life cycle stage deliverables Requirements Design Implementation May also require minimum functional mechanisms Increases trust that mechanisms are appropriate E.g. a certain access control model, level of cryptographic strength Assurance and trust Evaluation methodologies TCSEC Assurance point of view We can't currently make software that remains secure over time A system is trustworthy, if there is evidence that it meets given requirements; trust measures trustworthiness, relying on evidence Assurance is more specific: security assurance is confidence that a system meets its security requirements, based on evidence provided by specific assurance techniques Categorization of assurance techniques Informal natural language for specifications and justification of claims TCSEC ( ) Trusted Computer System Evaluation Criteria, a.k.a Orange Book Six evaluation classes: C1, C2, B1, B2, B3, A1 Each class contains both functional and assurance requirements Applies best to operating systems and access control Emphasizes confidentiality Developed as a standard methodology for devices processing government classified information Semiformal natural language used, but a specific methodology is used Formal mathematics, formal languages, automated tools and techniques In practice, evaluation methods use semiformal approach 30 32

9 Evaluation methodologies ITSEC Evaluation methodologies CC ITSEC ( ) European effort: France, Germany, UK, Netherlands,... Widely used before Common Criteria became available Six evaluation levels: E1 through E6 Assurance requirements Security functional requirements defined in a security target provided by vendor Functionality and assurance essentially separate But security targets often overlooked Common Criteria (... continued) Some terminology Protection Profile (PP) implementation-independent set of security requirements for a category of products Target of Evaluation (TOE) HW/SW under evaluation Security Target (ST) describes security requirements for TOE (based on a profile, or customized) TOE Security Policy (TSP) set of rules for managing security TOE Security Functions (TSF) HW/SW implementing the TSP ITSEC shortcomings for security targets addressed by profiles Evaluation methodologies CC Evaluation methodologies FIPS 140 Common Criteria (1998 Present) International effort: NIST + NSA, UK, France, Germany,... Three part standard The Common Criteria (CC) documents The CC Evaluation Methodology (CEM) Country-specific evaluation methodology (National scheme) The CC document describes overview of methodology and Identifies functional and assurance requirements Defines Evaluation Assurance Levels (EALs) The CEM document has detailed guidelines for evaluation However, each country implements the methodology in its own way FIPS and (1994 Present) Security Requirements for Cryptographic Modules NIST (National Institute for Standards and Technology, US) Security requirements cover 11 areas, including Basic design and documentation Key management Cryptographic algorithms Self testing Individual ratings (1...4) for each area, and overall rating (= minimum) Although hardware oriented, may be used for software as well Requires use of third party operating system etc, which is part of evaluation 34 36

10 Formal methods Formal methods are one way to gain assurance Correspondence between refinements can be proven to be correct Differences in many areas, e.g. Underlying mathematical method Degree of automation Property verification or full verification Domain of application HW/SW, concurrent/sequential, etc Pre- vs. post-development (design aid or verification) In practice can be applied only in limited scenarios A certain module A certain aspect of a module Informal and semiformal methods used in practice E.g. all practical evaluation methodologies Thank you! Questions? Summary Introduction to the second part of the course Requirements and design issues Threats, security models, assumptions Risk analysis Choosing a cryptosystem Common design principles Assurance and evaluation 38