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)

[1] http://en.wikipedia.org/wiki/Adi_Shamir
[2] http://freemind.sourceforge.net/

geeks in (work)space

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


http://www.google.com/logos/unix1234567890.gif