/
Security and access control

Security and access control

Owned by John Ousterhout
Last updated: Jun 02, 2009Version comment
  • To what degree should security and access control be built into the RAMCloud system?
  • What level of network security is needed?
    • Should every packet be encrypted?
    • Can assume that all packets originate and terminate with in the same datacenter
  • This issue relates closely to the multi-tenancy issue: there may be applications from mutually-distrustful companies executing in the same datacenter.
  • Who are the principals?
    • Individual server machine (but BFT too expensive)
    • Data servers as a group
    • Clients
  • Should clients trust data servers?
    • Servers could disclose private data to other clients in
      multi-tenancy setting
    • Servers could tamper with data
  • Should data servers trust clients?
    • Clients could request data they shouldn't be allowed to see
    • One client could tamper with another's data
  • One possible tool: crypto
    • Clients can encrypt data before storing it (but still hard to get
      any well-specified secrecy properties)
    • Clients can use a MAC/signature to verify data, but hard to ensure
      freshness.
    • Servers could cryptographically authenticate requests, but expensive
      • 1,280-bit Rabin-Williams: Sign in 1,515 usec, verify in 10 usec
      • 2,048-bit esign: Sign in 67 usec (20 usec if precompute), verify
        in 33 usec
      • AES block 150 nsec (mildly optimized C++ code)
      • AES Needham-Schroeder-like protocol 600 nsec
      • Sustained CBC encryption (CMAC should be similar) ~100 MB/sec
      • Poly1305/AES appears to require about 2 usec to verify 256-byte msg
  • Suggests we need to do security in the network for performance
    • Organize network topology so that addresses cannot be forged and
      authenticate based on addresses
    • Can possibly change bindings at medium-term scale
  • What access control should be enforced?
    • Probably want access control based on structure of keys. E.g.,
      keys could be <application-id, opaque-bits>, where each
      application-id has an ACL of addresses allowed access.
      • But that makes it hard to change permissions at a fine granularity
    • Might also want delegation--I.e., this third party app can read or
      write some of my facebook settings, but this seems much harder to
      do without cryptography.
    • Also, quotas probably very important in multi-tenancy situation
      • Limit amount of space, number of queries, etc.
      • When customer goes away, need to delete all of its data--or
        possibly archive somewhere then delete.