1. Partha Dasgupta, Arizona State University Consumer Identity and Consumer Computing Security Rev.2–Feb. 2004

2. Background u Personal Authentication  Stop ID theft u Hardware Based Security  Beyond TCG  HTM – Hardware Trust Management u Software based security  STM – Software Trust Management

3. If I didn't wake up, I'd still be sleeping.

4. “Look what a fine mess you've gotten us into, Ollie!”

5. Fine Mess? u The Internet for the masses, deployed about 9 years ago u Internet security measures phased in over the next 3-4 years:  SSL/IPSec  firewalls  antivirus software.  IDS systems  Certificates u Yet the e-commerce infrastructure is totally insecure  Viruses,  Phishing attacks,  Scams, Social Engineering u Identity theft and financial embezzlement are increasing at an alarming rate Pharming attacks, Rootkits more insidious methods coming

6. The Problem u Private information is easy to compromise  Viruses, keyboard sniffers, rootkits  Getting common and threats are significant u Financial and business information at risk  Money is involved  Losses can be large (even if consumers are not held responsible) u Trusted platform designs are immediately needed  All known software methods are at risk  Rootkits are undetectable u Viruses have “unlimited power”  Steal, cheat, fool, spoof, masquerade, change input/output A nickel ain't worth a dime anymore

7. Personal Identity Security u Identity  A property of humans, devices, entities  Authentication: “What you know, what you have and who you are”. u Transactions run on behalf of Alice MUST be initiated by Alice, with the knowledge of Alice. u Identity assurance in the present day is irretrievably broken.  Shared Secrets do not work u The Undeniable Truth: Any “private” information can and will be misused.

8. System Security u Network Security has been studied in depth and countermeasures deployed effectively  Sniffing  TCP-IP stack attacks  Firewalls  Replay attacks  Modification Attacks  DoS attacks u DoS vs. other attacks  DoS is not in the same class u System Security has taken a back seat  Virus detectors  Not effective Nero fiddled while Rome burned

9. “What is your Threat Model?” u To design effective security procedures we need a good threat model  Threat models formalizes risks  Solutions can be tailored to meet risks contained in the threat model  Realistic threat models are needed  Threat models can be “too strong” u The network security solutions are based on the “Internet Threat Model (ITM)”  Hosts are Secure, and trustable, the network is not. u What is a good threat model for system security? You should always go to other people's funerals. Otherwise they won't come to yours.

10. The Thompson Threat Model u Ken Thompson, Turing Award Lecture 1984  Reflections on Trusting Trust u Bottom Line:  If you did not write the code, and the compiler and the assembler you cannot trust a program u Software cannot be trusted. Ken Thompson: “The moral is obvious. You can't trust code that you did not totally create yourself…. “No amount of source- level verification or scrutiny will protect you from using untrusted code….. “A well installed microcode bug will be almost impossible to detect….

11. Viral Threat Model u The Thompson Threat Model (TTM) is “too strong”, u Viral Threat Model (VTM)  Network can be trusted; Hosts are not to be trusted.  Network security solved all network problem  Even without security, networks are remarkably secure u Why?  Viruses are pervasive and anti-viral software is myopic and ineffective.  General purpose software has continually shown vulnerabilities. u If all software is subject to viral threat, then the VTM becomes equivalent to TTM.  Modify the threat model to include trusted software You've got to be very careful if you don't know where you're going, because you might not get there.

12. Viral Threat Model u Viral Threat Model (VTM)  Network can be trusted; Hosts are not to be trusted.  Network security solved all network problem  Even without security, networks are remarkably secure u Why?  Viruses are pervasive and anti-viral software is myopic and ineffective.  General purpose software has continually shown vulnerabilities. –(Will not get fixed, installed base is large) u If all software is subject to viral threat, then the VTM becomes equivalent to TTM.  Modify the threat model to include trusted software

13. Modified Viral Threat Model u Some software is assumed to be immune to viral attack u Weaker, ineffective? u Cannot prevent every attack – but u Can we make threats low incidence and tolerable?  Like crime in society?  Detection, punishment, effective policies?  “Trust but Verify” Commodity applications have (and will have) vulnerabilities Commodity Operating Systems have (and will have) vulnerabilities We made too many wrong mistakes.

14. Bottom Line u No PKI, no security u Secure processors need a “human in the loop” u Human in the loop means the need for a human to see securely and communicate securely Secure Display Secure Keyboard (not software controlled) u Programmability may be a curse

15. Multi Factor Authentication What you know. What you have. Who you are. Password ID Card Biometrics Sniffable, phishable, leaky Depends on the card VERY VULNERABLE – not to be used for ID at a distance ID theft vulnerability

16. Multi Factor Authentication What you know. What you have. Who you are. Password ID Card Biometrics Sniffable, phishable, leaky Depends on the card VERY VULNERABLE – not to be used for ID at a distance ID theft vulnerability

17. Public Key Infrastructure u Too complicated (for consumers) u Unnecessary u Everything works “all right” without PKI u No one understands PKI u Will my grandma use PKI? Reality Check – nothing is working “all right” right now! Public Key Private Key Certificate Certificate Authority Keep this secret

18. Why PKI? u Can shared secret elimination be done?  Make all “secret information” public (privacy is a separate issue).  Use public keys as ID and challenge response as the authentication technique  Need mobile gadgets that work in e-commerce as well as brick and mortar locations  “Smart Cards” – PKI enabled u Bad news:  This approach is vulnerable to the VTM. u DoD Common Access Card  A well designed authentication system….. But……

19. Common Access Card u Private Keys are Secure on the card u Challenge response ensures non-spoofable identification and signatures u Certificates provide MITM resilience u All transactions can be signed by the card u A virus on the host can trick the card into performing signatures and challenge responses without the owner’s permission u PIN Phishing u Malicious Log-on u Fraudulent Signatures and transactions u Possible software download vulnerabilities

20. Solution? u Human in the Loop u Each time a PKI operation is performed a human has to know what is going on  Need out of band methods for verfication of trasactions  Cell phone calls? u Research Issue 1:  How to put the human in charge? u Research Issue 2:  How to minimize human interference, without compromising security? This is Secure Yeah, Right

21. Security Appliance Computer Applications Web Browser Plug-ins Viruses Secure Processor PKI software Keys Certificates Trusted keys NOT secure Secure – preferably non- programmable

22. More Secure Devices u Mobile devices u Movable devices u Wireless enabled u Infrastructural devices u Server Security Products u Anti Virus Protection u “Secure Downloads” “Secure” Processor Bus Access OS Check the OS for untrusted code Check the Applications for untrusted code Applications

23. MVTM Software Approach u How to secure computing systems under the MTVM? u What is the solution under MVTM?  Some software has to be declared trusted!  Trusted software: Functions as advertised, independently verified, cannot be “easily” compromised  Compromise of trusted software should be detectable  Hardware techniques may be used to “check” or “verify”  Trust delegation – trusted software can declare other software to the trusted (trust level would be lower). Leads to hierarchies of trust. u Above solution is a start, we plan to refine it.

24. Two Approaches u The Software Approach  A VMM that is trusted [augment with hardware checking]  The VMM checks on the OS  Add vault features to VMM [not advisable, see later]  Secure human I/O needed u The hardware approach  Have a hardware “OS” in hardware  Vault + Checker for software OS [similar to the software above]  Works independently from the software (is the “boss”)  Has complete access to physical memory (and virtual memory)  Secure human I/O needed u Both approaches need “Human in the Loop”

25. Hierarchical Trust Management u Chain of “Checkers” u Levels of Trust  Need not be single chain

26. Attacking a VMM Application OS VMM Rootkit the OS Rootkit the VMM Install Attack Code Attacker VMMs are not impervious, but they may be harder to attack and can be made hardened

27. Securing the VMM u VMM is small, vulnerability testing can be simpler (hopefully)  Do not include networking support in VMM  Do not include security/trust management in VMM u VMM can check OS for rootkits  OS can run virus detectors for applications  “Signed applications only” for secure systems u Add a special trusted system as a HOS on VMM: Security Manager - SM  SM can check VMM for rootkits [verification]  VM can check SM for rootkits [verification]

28. The Software Trust Manager u SM is a small OS+Application suite that runs in a separate virtual machine u It has at least the following:  Network Stack and Termination  SSL-IPSec terminations  NAT Server, DHCP  Key Vault + Signature software  Stores hashes of applications/OS/VMM  Stores trusted public keys  Secure I/O to human u Functions:  Checking Software, Signature Verification  Digital signatures  Human in the Loop - policies

29. Why Humans? u SM needs to “talk” to a human, and know its talking to a human WHY?  Sign financial transactions  Authentication, logging into secure sites  Updating keys, certificates  Updating hashes, trusted public keys  Provide Alerts  More? u HOW?  Separate hardware channel, separate hardware display/keyboard No system can be made secure without a secure human interface!

30. Key things u Security = Private keys + humans + key vaults + hash checks on software u PKI is essential for authentication (shared secrets are a problem). u “Trusted Public Keys” and “Trusted Hashes” need human verification u Any financial transaction signing should use human verification u Bottom Line: Prevent viruses, and yet assume viral attacks will happen and create defenses for that situation

31. Trusted Hardware TCG/TPM u A good direction  Hardware is resilient to tampering, cannot be reprogrammed easily  Secure vault for keys/certificates u Vulnerabilities  TPM can be “fooled” by viral software  TPM is under the control of the OS – can be bypassed  Complex software layers – may have vulnerabilities If the world were perfect, it wouldn't be.

32. The HTM Approach u Use a Hardware Module to check the Operating System u HTM must have secure I/O to user

33. Combined Trust Hierarchy Hardware Checker VMM SM HOS Antivirus Signed apps app

34. Near Term Research Plan u Fast Prototyping:  VMM off the shelf with minor modifications  SM: Application run on stock OS  SM: Add cryptographic protocols and  SM: Secure I/O is simulated  Hardware checker is an FPGA board  VMM OS rootkit detector, with simple hashing scheme u Testing and Verification  Insert code into applications and operating systems using “helpers” to check detection capabilities  Attempt to update VMM or SM and/or hardware simulator I really didn't say everything I said.

35. Conclusions u System Security is the next frontier u Cryptography is useless when keys can be stolen u Shared secret schemes are bad, public keys can be ineffective too. u Integrated design needed:  Human  Verification  Some hardware or robust software + protocols + protocols + policies