Preview question Whats common about the Common Criteria? A. Every - PDF document

Preview question What’s “common” about the Common Criteria? A. Every kind of product is evaluated against the same “protection CSci 5271 profile.” B. Anyone can perform the certification, without special government Introduction to Computer Security approval. Capabilities, side channels, OS assurance C. The certification applies to devices used in everyday civilian life, rather than in government or the military. Stephen McCamant D. A single certification is recognized by the governments of many University of Minnesota, Computer Science & Engineering countries. E. A single certification can be used for products from different vendors. Outline (Object) capabilities Capability-based access control (cont’d) A capability both designates a resource and Side and covert channel basics provides authority to access it Similar to an object reference Announcements intermission Unforgeable, but can copy and distribute Transient execution covert channels Typically still managed by the kernel OS trust and assurance Capability slogans (Miller et al.) Partial example: Unix FDs No designation without authority Authority to access a specific file Dynamic subject creation Managed by kernel on behalf of process Subject-aggregated authority management Can be passed between processes No ambient authority Though rare other than parent to child Composability of authorities Unix not designed to use pervasively Access-controlled delegation Dynamic resource creation Distinguish: password capabilities Revocation with capabilities Use indirection: give real capability via a pair of Bit pattern itself is the capability middlemen No centralized management ❆ ✦ ❇ via ❆ ✦ ❋ ✦ ❘ ✦ ❇ Modern example: authorization using cryptographic Retain capability to tell ❘ to drop capability to ❇ certificates Depends on composability

Confinement with capabilities OKL4 and seL4 Commercial and research microkernels ❆ cannot pass a capability to ❇ if it cannot Recent versions of OKL4 use capability design from communicate with ❆ at all seL4 Disconnected parts of the capability graph cannot be Used as a hypervisor, e.g. underneath paravirtualized reconnected Linux Depends on controlled delegation and data/capability Shipped on over 1 billion cell phones distinction Joe-E and Caja Outline Capability-based access control (cont’d) Dialects of Java and JavaScript (resp.) using Side and covert channel basics capabilities for confined execution Announcements intermission E.g., of JavaScript in an advertisement Note reliance on Java and JavaScript type safety Transient execution covert channels OS trust and assurance More confidentiality problems Side channel vs. covert channel Careful access control prevents secret data from Side channel: information leaks from an “leaking” though normal OS-mediated unsuspecting victim Covert channel: information intentionally leaked by a communication channels adversarial sender Residual problem: channels not designed for Violating an isolation property communication Sender and receiver work together A major theme of ongoing computer security Distinction sometimes unclear or not observed research Kinds of channels Classic software covert channels Software channels: undesired feature of program Storage channel: writable shared state behaviors E.g., screen brightness on mobile phone Physical channels: channels mediated by the real Timing channel: speed or ordering of events world E.g., deliberately consume CPU time Hardware channels: undesired feature of hardware behaviors

Remote timing and traffic analysis Examples of physical side channels Timing of events can also leak over the network EM emissions and diffuse reflections from CRTs Classic example: time taken to process encrypted data Power usage of computers and smart cards Encrypted network traffic still reveals information via pattern and timing of packets Smartphone accelerometer picks up speaker Classic example: keystrokes over SSH vibrations Modern: “website fingerprinting” against HTTPS and Tor Common hardware channel: cache timing Outline Capability-based access control (cont’d) Memory cache shared by processes and sometimes Side and covert channel basics cores Cache state depends on pattern of previous Announcements intermission accesses Transient execution covert channels Cache hit or miss affects code execution speed OS trust and assurance Multiple BCMTA vulnerabilities found! Midterm exam next Monday Usual class time and location Covers up through today’s lecture material Format string vulnerability in logging Mix of short-answer and exercise-like questions Race condition on file ownership check Open books/notes/printouts, no computers or other Instruction whitelist was too permissive electronics Sample exams (2013-2019) posted, solutions Wednesday Exercise set 2 Reversing the stack Due Wednesday evening ✈♦✐❞ ❢✉♥❝✭❝❤❛r ✯str✮ ④ ❝❤❛r ❜✉❢❬✶✷✽❪❀ Join pre-created groups in Canvas str❝♣②✭❜✉❢✱ str✮❀ Remember to cite any outside sources you used ❞♦❴s♦♠❡t❤✐♥❣✭✮❀ May not be graded before midterm, so ask r❡t✉r♥❀ questions early ⑥

Payment app Reverse range ✈♦✐❞ r❡✈❡rs❡❴r❛♥❣❡✭✐♥t ✯❛✱ ✐♥t ❢r♦♠✱ ✐♥t t♦✮ ④ ✈♦✐❞ ♣❛②♠❡♥t✭❝❤❛r ✯♥❛♠❡✱ ❞♦✉❜❧❡ ❛♠♦✉♥t❴❥♣②✱ ✉♥s✐❣♥❡❞ ✐♥t ✯♣ ❂ ✫❛❬❢r♦♠❪❀ ❝❤❛r ✯♣✉r♣♦s❡✱ ✐♥t ♣✉r♣♦s❡❴❧❡♥✮ ④ ✉♥s✐❣♥❡❞ ✐♥t ✯q ❂ ✫❛❬t♦❪❀ ❞♦✉❜❧❡ ❛♠♦✉♥t❴✉s❞ ❂ ❛♠♦✉♥t❴❥♣② ✴ ✶✵✾✳✷✸❀ ✇❤✐❧❡ ✭✦✭♣ ❂❂ q ✰ ✶ ⑤⑤ ♣ ❂❂ q ✰ ✷✮✮ ④ ❝❤❛r ♠❡♠♦❬✸✷❪❀ ✯♣ ✰❂ ✯q❀ str❝♣②✭♠❡♠♦✱ ✧P❛②♠❡♥t ❢♦r✿ ✧✮❀ ✯q ❂ ✯♣ ✲ ✯q❀ ♠❡♠❝♣②✭♠❡♠♦ ✰ str❧❡♥✭♠❡♠♦✮✱ ♣✉r♣♦s❡✱ ♣✉r♣♦s❡❴❧❡♥✮❀ ✯♣ ❂ ✯♣ ✲ ✯q❀ ✇r✐t❡❴❝❤❡❝❦✭♥❛♠❡✱ ❛♠♦✉♥t❴✉s❞✱ ♠❡♠♦✮❀ ♣✰✰❀ q✲✲❀ ⑥ ⑥ ⑥ Outline Outline Capability-based access control (cont’d) Capability-based access control (cont’d) Side and covert channel basics Side and covert channel basics Announcements intermission Announcements intermission Transient execution covert channels Transient execution covert channels OS trust and assurance OS trust and assurance Trusted and trustworthy Trusted (I/O) path Part of your system is trusted if its failure can break How do you know you’re talking to the right your security software? Thus, OS is almost always trusted And no one is sniffing the data? Real question: is it trustworthy? Example: Trojan login screen Distinction not universally observed: trusted boot, Or worse: unlock screensaver with root password Origin of “Press Ctrl-Alt-Del to log in” Trusted Solaris, etc. Minimizing trust How to gain assurance Use for a long time Kernel ✦ microkernel ✦ nanokernel Testing Reference monitor concept Code / design review TCB size: measured relative to a policy goal Third-party certification Reference monitor ✒ TCB But hard to build monitor for all goals Formal methods / proof

Evaluation / certification Orange book OS evaluation Trusted Computer System Evaluation Criteria Testing and review performed by an independent party D. Minimal protection C. Discretionary protection Goal: separate incentives, separate accountability C2 adds, e.g., secure audit over C1 Compare with financial auditing B. Mandatory protection Watch out for: form over substance, misplaced B1 ❁ B2 ❁ B3: stricter classic MLS incentives A. Verified protection Common Criteria Common Criteria, Anderson’s view International standard and agreement for IT security Many profiles don’t specify the right things certification OSes evaluated only in unrealistic environments Certification against a protection profile , and E.g., unpatched Windows XP with no network attacks evaluation assurance level EAL 1-7 “Corruption, Manipulation, and Inertia” Evaluation performed by non-government labs Pernicious innovation: evaluation paid for by vendor Labs beholden to national security apparatus Up to EAL 4 automatically cross-recognized Formal methods and proof Proof and complexity Can math come to the rescue? Formal proof is only feasible for programs that are small and elegant Checking design vs. implementation If you honestly care about assurance, you want your Automation possible only with other tradeoffs TCB small and elegant anyway E.g., bounded size model Should provability further guide design? Starting to become possible: machine-checked proof Some hopeful proof results seL4 microkernel (SOSP’09 and ongoing) 7.5 kL C, 200 kL proof, 160 bugs fixed, 25 person years CompCert C-subset compiler (PLDI’06 and ongoing) RockSalt SFI verifier (PLDI’12)