Skip to content

Latest commit

 

History

History
84 lines (68 loc) · 3.68 KB

Integrating Security in a Large Distributed System.md

File metadata and controls

84 lines (68 loc) · 3.68 KB
Raw

#Integrating Security in a Large Distributed Environment

Goals in 1988:

  • Walk up to any workstation in the campus and be able to access your data
  • Similar to cloud + mobile devices today!

Andrew architecture:

  • Client workstations, are called Virtues in here
  • Virtues connect to LAN (insecure link)
  • LAN contains Servers (Vice) which talk with one another (secure link)
  • Since Virtues to LAN connection is insecure, it should be encrypted

Virtues run UNIX:

  • Process Venus runs on workstation for user authentication and client caching
  • Venus authenticates and fetches the files using RPC to the Vices
  • RPC connections are encrypted via symmetric keys (only private keys, so paasswords for example)

Key challenges for Andrew systems

  • Authenticate users
  • Authenticate servers
  • Prevent replay attacks
  • Isolate users info from one another

Their choice in Andrew was to solve these by RPC with private key crypto systems

  • The identity of the sender has to be sent in cleartext in this scenario
  • username and password are only for login into a workstation
  • in order to not expose those 2 keys very often, for the next RPC calls:
    • ephemeral ID and keys are used for authentication

Three classes of client server interaction

  • login -> username, password
  • RPC session establishment
  • file system access during session

Login process:

  • virtue sends username/pw to vice
  • vice returns secret token and clear token
  • virtue extracts handshake key client (hkc) from cleartoken
    • for the duration of the login session, hkc can be used as private key
  • secret token is the cleartoken encrypted with key only known to vice
  • secret token is unique for this login session
    • can be used as an ephemeral client_id for this login session

RPC session establishment (bind client-server)

  • clientIdentity, E[X0,HKC] (sent from client to server)

    • clientIdentity is cleartext, and it's the secret token
    • X0 is a random #, new for each RPC
    • HKC was extracted from the cleartoken

  • E[(Xr+1, Yr), HKS] (sent from server to client, prove server genuinity)

    • client can decrypt this message by using HKC
    • Once decrypted, client will see x0+1 which proves it's a response from the server
      • keep in mind only the server could know what x0 is, so x+1 proves its genuine
    • Yr is a random number generated by server, similar to Xo

  • E[(Yr + 1), HKC] (sent from client to server, prove client genuinity)

    • only the client knows about Yr, so sending Yr+1 proves its really the client

  • This trick of sending random nubmers by Xr and Yr, helps avoiding replay attacks

  • E[(SK, seq_num), HKS] (sent from server to client)

    • SK is used as the handshake key for the rest of the RPC session with server
    • SK stands for session key
    • seq_num is a trick against replay attacks, allows client and server to know the order of the RPC sessions

Login as a special case of RPC bind

  • password is used as the HKC
  • Username used for clientIdent
  • gets back two tokens, secretToken/clearToken encrypted with password

Upshots of AFS

  • username, pw is exposed only once per login session
  • HKC only used for a new RPC session, and its duration is for the login sesion
  • secret token and session key useless after user logs out
  • session key is valid only for one RPC session, can't be reused

Challenges of AFS:

  • mutual suspicion (of server by client and viceversa) - good
  • authentication both ways - good
  • server integrity (NO)
  • Protection from system for users (NO) - gotta trust the server...
  • Confinement of resource usage (NO) - gotta trust the user... DOS attacks