/
Security and access control

Security and access control

Jun 02, 2009

  • 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.