Security In Andrew
Summary
- State of Computing circa 1988
- Andrew Architecture
- Encryption Primer
- Challenges for Andrew File System
- Login Process
- RPC Session Establishment
- Putting it All Together
State of Computing circa 1988
Workstations conneccted to central server over lan
- local disks served as caches
Andrew Architecture
Client workstation
- Unix
- Called virtues
Servers are clusted in secure environment
- Called vice
- Secure
Clients need to access servers over insecure links
Process called Venus used for auth and client caching
Encryption Primer
Private Key System
- Symmetric keys used in login
- like password
Public Key System
- Asymmetric keys
- Public key published
- Used to encrypt
- Private key hidden
- Used to decrypt
- Public key published
Challenges for Andrew File System
- Authenticate users
- Authenticate server
- Prevent replay attacks
- Isolate users
Private key crypto system
Identity of sender in cleartext
Overuse of both username and password is a security hole
- Over-exposing key makes it easier to break key
Solution
- Username and Password only for login
- Use ephemeral id and keys for subsequent venus-vice communication
3 classes of client-server interaction
- login
- RPC Session Establishment
- FS Access during session
Login Process
2 Data strucutures:
- cleartoken
- extract handshake key client (HKC)
- secrettoken
- cleartoken encrypted with key known only to vice
- unique for this login session
- used as ephemeral client_id
Venus uses secretoken as the client id and the RPC messages are encoded with HKC
RPC Session Establishment
Incrementing random number by 1 proves that sender is genuine
num is the starting sequence number for RPC
Login is a Special Case of Bind
- Username is used for clientIdent
- Password is used as HKC
- Get back two tokens, encrypted with password
- secrettoken
- cleartoken
Putting it All Together
Username and password are only used once per login session
HKC used only for a new RPC session
SK used for all RPC calls to a filesystem