Monday, February 16, 2009

conference: Security Clouds in the Horizons --by Adi Shamir

I had the invaluable chance to attend Adi Shamir [1]'s conference "Security Clouds in the Horizons" or "Why I'm skeptical about Cloud Computing", given at Google's offices.

Below are my ~raw notes (taken with Freemind[2], then exported to HTML), meaning: a GiAnT disclaimer about the possible inaccuracy of these, YHBW.
  • Cloud Computing
    • [def] from wikipedia (~fine)
      • dynamically scalable virtualised resources
      • as a service
      • over the Internet
    • "... not new to me" [sic]
      • 1960 -> John McCarthy : cimputation may someday be organized as a public utility
        eg. municipality -> computaion bureau
      • 1960: small number of large service centers
      • 1980: small companies with self managed DC (data center)

  • Q: Which type of system should be more secure in principle: Cloud or Self-managed ?
    • Cloud:
      • more experienced companies
      • -> more secure systems
      • -> BUT more attractive TARGETS for attacks
    • Computer insecurity
      • old problem, 1st recorded incident: RFC 602 (at ARPANET, aprox 100 computers)
  • Safety vs security [definition]
    • Safety
      • "YOU vs NATURE"
        • reliability issues, etc
      • difficult to achieve
        • eg. building a car which is perfectly safe to drive
          • very complicated
          • very expensive
          • very slow and cautious
    • Security
      • _MALICIOUS_
        • ++harder to deal
          • they know your defensive measures
          • they know your weaknesses
        • eg. design a car that resist eg
          • dropping sugar in the gas tank
          • putting explosives near the engine
  • Q: Is cloud computing more secure than company-centric computing?
    • 1: remote data storage
      • privacy
        • no problem iff KEY is *local* (send/store only encripted data)
      • reliability
        • much better for the cloud
    • 2: remote code execution
      • security of the data IN the hands of the provider (!)
      • diff. types of threats [classif]:
        • dishonest employees
          • a single "bad apple" can cause a LOT of damage
        • amateur hackers (script kiddies)
          • motivation proportional to SIZE
          • for recognition/ego
        • professional hackers (data thieves)
          • make money, spionage, etc
          • they carefully choose their target,
            they spend time and money for the attack, etc

          • ++attractive to break bigger systems
          • ++motivation: *high* reward/effort ratio
        • cyber terrorists using sophisticated cross border attacks
          • motivation: create *PANIC*
            • economic damage
            • make ppl to not trust
              • banks, govt, etc
        • discreet govt intervention
          • terrified by being discovered
            (political fallout of public disclosure)
            • ++risk if cloud (vs small DCs)
          • they ARE applying pressure (no doubt!)
      • Can cryptography solve the security issue ?
        • theoretical solutions
          • multiparty computation protocols
          • totally UNREALISTIC
          • VERY difficult
    • How do you BREAK the security of cloud computing ?
      • side channel attacks
        • use phyisics to overcome math
        • cryptanalytic attack: "cache attacks"
          • pure software attack
          • very efficient
          • full 128bit AES key extraction from Linux encrypted file system in 65ms
            • require only the ability to run code in parallel on the target physical location
          • can compromise eg VPN/aes =)
          • can be used to attack any Virtualization technique
            (jail, Xen, UML, Virtual PC , VMware)
          • very hard to protect against WITHOUT a major performance penalty
          • solution? turn off caching when encrypting ?
            • problem: @BIOS setup
            • speed (!)
          • HOW is the attack done:
            • look for the time delay in accessing mainmem vs cache while accessing the idx in the 1st table lookup, because:
            • for AES: finding the KEY == finding the INDEX of the 1st lookup table for a known plaintext *and* you can force the plaintext (eg encrypted harddisk, vpn).
        • another example: normal PC "noise"
          • signal processing of that noise, correlated to diff CPU ops, using FFT: patterns clearly shown, eg:
            • RSA key generation
            • HLT, MUL, ADD, etc
            • found: 2nd power supply capacitors
      • big problem with "virtualization":
        • the UNDERLYING physical CPU *is* the same
          • by stressing the "common" underlying resource
            another process @another VM can "discover"
            this sharing

        • using birthday paradox, you can reasonably "discover":
          • aprox number of physical processors in the network
          • aprox number of VMs
          • Virt-to-Phy processor allocation "spread" (eg for loadbalancing load/resources)

geeks in (work)space

It's cool to be surrounded by freaking geeks at work, better yet when this geekiness becomes visible ;)