05-security.md

---

title: Security notebook: Distributed Systems layout: note date: 2020-10-15 tags: ...

0 TODO: add link to comp systems summary <15-10-20, yourname> 0

[[toc]]

Challenges of Security

• challenges arise due to need to share/distribute resources
• security policy: statement of required integrity and privacy of shared information
  • other limits to allowable usage of shared resource
• security mechanism: enforces a security policy
  • cryptography is the basis of most mechanisms

Threats and Attacks

Threats

• threat: possible means of malicious use of/interference with a system

Main classes of security threats

• leakage: acquisition of information by unauthorised recipients

• tampering: unauthorised alternation of information

• vandalism: interference with proper operation of a system without gain to perpetrator

• obvious threats: reading traffic on shared network

• unobvious threats: pretending to be official server

Attacks

• attack: exploit of a threat

• depend on access to existing communication channel

• misuse of communication channel can take various forms

• eavesdropping: obtaining copies of messages without authority

• masquerading: sending/receiving messages using the identity of another principal without their authority

• message tampering: intercepting messages, and altering their contents before passing them on

  • e.g. man-in-the-middle attack

• replaying: storing intercepted messages and sending them at a later date

• denial of service: flooding a channel or other resource with messages in order to deny access to others

Threats from Mobile Code

• when distributed system allows code to be communicated for execution by other hosts, it needs to provide protection to ensure that the host is secure from operations the mobile code undertakes while permitting legitimate operations
• e.g. code delivered in email or via web browser: OS usually asks user whether code should be trusted or not
• Java VM: sandboxed to ensure mobile code is not a security risk
  • gives each application its own environment, which has its own security manager that determines available resources
  • security manager cannot be replaced once set
  • JVM stores downloaded classes separately to local classes to prevent replacement with malicious variants
  • bytecodes are checked for validity, and that instructions won't access illegal memory addresses
• producing secure environments for running mobile code is more challenging than providing secure channels

Information Leakage

• observing transmission of a message can reveal information: e.g. flood of messages to stock broker regarding a particular stock may signal high level of trading
• can be very difficult to prevent
• system must appear to be random in order for no information to be leaked

Securing Electronic Transactions

• many Internet uses require secure transactions
• email: personal info, used for authentication
• purchase of goods & services: payments via web interface, delivery of digital products
• banking transactions
• micro-transactions

Example security policies

• authenticate vendor to buyer so buyer is confident server is operated by vendor
• ensure credit card + personal details are transmitted unaltered and privately
• responses from the vendor should be received without alteration or disclosure during transmission
• authenticating buyer not usually required, as long as payment is received

Designing Secure Systems

• known threats can be listed, designer can document how threats are addressed
• logs can be used for audit and to determine security violations
• costs of implementing policy need to be traded against threat
• security should not needlessly inhibit legitimate uses

Worst case assumptions

• interfaces are exposed: e.g. socket interface is open to the public
• networks are insecure: messages can be looked at, falsified, copied
• algorithms and program code are available to attackers:
  • the larger the secret the greater the risk of its disclosure
  • open source provides benefit in finding security problems, and scrutiny of methods
• attackers may have access to large resources
  • note Moore's law: resources of attackers are likely to grow exponentially over the lifetime of the product

Design Guidelines

• minimise the trusted base
• limit the lifetime and scope of each secret

Cryptography

• public key encryption algorithms: 100-1000x more processing power than symmetric algorithms

Standard participants

• Alice, Bob, Carol, Dave: general participants
• Eve: eavesdropper
• Mallory: malicious
• Sara: server

Notation

• $k_B$ Bob's secret key
• $k_{ AB }$ shared secret key between Alice and Bob
• $k_{A\text{ priv }}$ Alice's private key: known only to Alice
• $k_{ A\text{pub}}$ Alice's public key: shared freely
• ${M}_k$ message $M$ encrypted with key $k$
• $[M]_k$ message $M$ signed with key $k$
• ${M}_k = E(M, k), M = D({M}_k, k)$
  • $E$ encryption algorithm
  • $D$ a decryption algorithm

Scenario 1: Secret communication via shared secret key

• fundamental policy: ensure secrecy of message

Alice and Bob share a secret key $k_{AB}$, and agree upon an encryption/decryption algorithm.

If the decrypted message makes sense or contains an agreed upon-value (checksum etc), Bob can be confident:

• the message came from Alice
• the message hasn't been tampered with

Issues

• how to securely send the shared key?
• how can Bob know any message is not a replay?

Alice needs to send something with the message so that Bob can verify it isn't a replay

Scenario 2: Authenticated communication with a server

• Alice wants to access Bob's resource.
• Sara is a securely managed authentication server.
• Sara issues passwords to all users, and knows secret keys $k_A, k_B$, as they are derived from the passwords.
  • user passwords aren't transmitted over the network
• ticket: encrypted item issued by authentication server, containing the identity of the principal and a shared key generated for the current communication session

1. Alice sends a plaintext message to Sara stating identity and requesting a ticket for access to Bob
2. Sara sends a ticket ${K_{AB}, \text{Alice}}{K_B}$ to Alice encrypted with $k_A$ containing ticket encrypted by $k_B$, and a new secret key $k{AB}$: ${{\text{Ticket}}{K_B}, K{AB}}_{K_A}$
3. Alice decrypts with $K_A$, giving a ticket for Bob and a shared key:
   • Alice can't tamper with the ticket, as it's encrypted with $K_B$
4. Alice sends the ticket to Bob with her identity and request $R$ to access a file: ${\text{Ticket}}_{K_B}, Alice, R$
5. Bob decrypts the ticket with $K_B$, allowing him to confirm Alice's identity, and establishes a shared session key $K_{ AB }$

• this approach is simplified version of that used in Kerberos
  • full version includes protection against replay attacks and other weaknesses

Issues

• how to trust server?
• how to enrol in the system?

Scenario 3: Challenge-response

• authentication server is only practical when all users are part of a single organisation
• challenge-response technique: identity of a client is established by sending the client an encrypted message
  • only the client should be able to decrypt it
  • if the client cannot decrypt the message, they cannot properly respond
• common use: avoid sending passwords in the clear

Scenario 4: Authenticated communication with public keys

• Alice accesses key distribution service Sara to obtain a pub-key certificate Cert giving Bob's public key, signed by Sara using $k_{Spriv}$
  • $k_{Spub}$ is widely known, so Alice can used it to check the signature
  • the certificate contains $\text{Bob},\text{keyname},k_{Bpub}$
• Alice creates $k_{AB}$ and encrypts it using $k_{Bpub}$
• Alice sends this to Bob, with a name identifying the public/private key pair (Bob may have multiple)
  • ${\text{keyname}, k_{AB}}{k{Bpub}}$
• Bob decryptes the message with $k_{Bpriv}$ to get $k_{AB}$
• Alice and Bob can now communicate securely
• if the message was tampered with, $k_{AB}$ won't match, and the messages Bob sends back to Alice will be garbled

Digital Signature

• digital signature: binds an identity to a message
  • for public/private key exchange, the identity is the key pair itself
  • verifies to third party that a message/document is an unaltered copy of the one produced by the signer
• provides
  • authentic
  • unforgeable
  • non-repudiable
• digest $Digest(M)$: maps an arbitrary message $M$ to a fixed length message
  • e.g. SHA-1
• Alice wants to sign $M$, so constructs $M,{Digest(M)}{k{Apriv}}$
• Receiver Bob decrypts the digest using $k_{Apub}$
• Bob computes digest of $M$ locally. If the message/digest have been tampered with, the results won't match
• signature based on identity $k_{Apriv}$:
  • no other private key would produce that encrypted digest
  • no other message is likely to produce that digest
  • non-repudiation: Alice cannot deny having signed the message

MACs - Digital signatures with secret keys

• public-key method is most convenient most of the time:
  • difficult to securely transmit secret key used for signing, ...
• when a secure channel is used to transmit unencrypted messages, but an authenticity check is needed, Message Authentication Codes can be used
  • more limited purpose
  • authenticate communication between pairs of principals using a shared secret

• performance advantage over pub-key digital signatures: no encryption
• TLS supports variety of MACs

Certificates

• digital certificate: document containing statement signed by a principal
  • principal's public key must be known to anyone who wants to authenticate the certificate
  • principal is known as certifying authority
• e.g. Bob is a bank.
  • Customers establish contact for the first time. They need to know they are talking to Bob
  • Bob needs to authenticate customers before giving account access
• might contain information like:
  • Certificate type: public key
  • Name: Bob
  • Public key: $k_{Bpub}$
  • certifying authority: Sara
  • Signature: ${Digest(name+k_{Bpub})}{k{Spriv}}$
• certificate says "Sara certifies Bob's public key is $k_{Bpub}$"
• Sara cannot deny this attestation

Certificate Chain

• for Alice to authenticate a certificate from Sara, Alice first needs Sara's public key
  • recursive problem
• e.g. certificate chain: assume Carol signs certificate attesting to Bob's public key
  • Sara has signed a certificate attesting to Carol's public key
  • if Alice trusts Carol's certificate she can authenticate Bob's identity
  • otherwise, Alice first needs to authenticate Carol's identity using Sara's certificate
• certificate revocation: usually uses expiry dates
• how do you choose a trusted authority from which a chain of authentications can be built
• a number of root certificates are installed with each browser/operating system from which certificate chains ccan be constructed

• X.509: standard for digital certificates

Cryptographic Algorithms

• symmetric/shared key
  • e.g. AES: variable block length and key length
• asymmetric
  • e.g. RSA: security from difficulty of factoring large primes
  • weakness: attacker has public key, so can attempt to encrypt all possible messages to find one that matches
    • defend against this by only encrypting messages with at least as many bits as they key. then the attack is equivalent to trying all possible keys
• block ciphers: operate on fixed size blocks of data (e.g. 64 bits)
  • message is subdivided into blocks, with last block padded out
  • each block is independently encrypted
  • blocks are transmitted as soon as encrypted
• cipher block chaining: avoids problem of identical plain text blocks being encrypted to identical encrypted blocks
  • if the same message is sent to different recipients, it will still look the same, posing an information leakage weakness
  • initialisation vector used to guard against this by starting each message in a different way
• stream cipher: used when data cannot be easily divided into blocks
  • key stream is agreed upon (from a RNG with known seed)
  • output is XORed with data stream

Cipher Block Chaining (CBC)

• encryption: each plaintext block is XORed with the preceding encrypted block
• decryption: block is decrypted, and preceeding encrypted block is XORed with it to obtain new plaintext block
• works because XOR is its own inverse

Transport Layer Security

• TLS succeeds Secure Socket Layer (SSL) protocol
• intent: provide flexible means for client and server to communicate using a secure channel
  • without having negotiated previously about how to do so
• adds secure communication layer below existing application-level protocols
• widely used to secure HTTP interactions https:
• prevents eavesdropping, tampering, message forgery
• typically server is authenticated, client is unathenticated (however both can be authenticated if required)
• only requirement: pub-key certificates are issued by authority recognised by both parties

Handshake Protocol

• peer negotiation for algorithm support
  • choose cipher, compression, connection parameters
• key exchange using pub-key encryption, with certificate based authentication
  • master secret: negotiated and used to generate all other key data
• symmetric cipher-based traffic encryption

Security Measures

• records are numbered
• sequence numbers are included in signatures
• message ending the handshake sends hash of all exchanged data seen by both parties
  • hashing: XOR results of both MD5 and SHA in case one is vulnerable

Protocol stack

• TLS consists of 2 layers
• Record Protocol: implements secure channel (session-level layer)
  • encrypts, authenticates messages transmitted through any connection-oriented protocol
• Handshake Layer: (plus other protocols) establish and maintain TLS session between client and server
• both are implemented at application level in client and server

Record Protocol

Java secure server

• Java secure server/client: need to use a keystore file which contains certificates and other data needed for SSL

Kerberos

• ticket-based authentication scheme focused on authenticating identity of clients to server
• provides protection against
  • eavesdropping
  • replay
• developed at MIT in the 80s as a campus-wide networking for undergraduate education
• assumptions
  • clients not trustworthy: user-developed software could be run on computers
  • network not secure
• default authentication service in Windows

Security Objects

• ticket: token issued to a client by ticket-granting service

  • presented to a particular server, verifying the sender has recently been authenticated by Kerberos
  • has expiry time (typically a few hours) and a new session key for use by client/server

• authenticator: token constructed by a client, sent to a server to prove the identity of the user,

  • only used once
  • contains client name, timestamp
  • encrypted in session key

• session key: secret key randomly generated by Kerberos

  • issued to a client for use when communicating with a particular server

• clients possess a ticket + session key for each server they use

Architecture

• Key Distribution Centre (KDC): Kerberos server
  • provides authentication service (AS) and ticket-granting service (TGS)
• on login, users are authenticated by AS using network-secure password method
• client is provided with a ticket granting ticket, plus a session key for communicating with the TGS
• Needham-Schroeder protocol followed
• uses time values as nonces
  • to guard against replay attacks
  • to apply ticket lifetime

Implementation

• server running on a secure machine
• set of libraries provided for client applications and services
• scalable: world is divided into realms, domains of authentication authority, each with its own Kerberos server