Distributed System Security

Two Core Problems of Distributed Security

A conventional operating system can protect only the hardware it directly manages. Once computation spans multiple machines two fundamental obstacles appear. A remote participant may simply ignore agreed policies or may be an adversary impersonating a trusted partner; its internal state cannot be inspected. At the same time the network that carries the messages is typically uncontrolled, allowing an attacker to forge, copy, replay, alter, destroy or delay packets. Cryptography is the principal countermeasure, yet it must be applied through carefully engineered standard protocols rather than homemade constructions.

Authenticating Parties Across a Network

Because a remote computer cannot be observed, it is authenticated by a secret that only it should possess. Passwords fit the case of many clients proving themselves to one server, each client remembering a unique string that the server stores in salted hashed form. Public-key cryptography fits the opposite case: one server proves itself to countless clients by means of a single private key whose matching public key is widely distributed. Any password that travels the network must already be protected by an established cryptographic channel; otherwise an eavesdropper simply records it.

Digital Certificates and Certification Authorities

A public key is useless unless we know with certainty to whom it belongs. A certificate packages an identity, a public key and auxiliary data such as an expiration date, then has the whole package digitally signed by a trusted third party called a certification authority (CA). Anyone who already possesses the CA’s public key can check the signature and thereby obtain a trustworthy copy of the subject’s public key without a prior face-to-face meeting. The security of the scheme ultimately rests on the CA’s diligence in verifying identities and protecting its own private key.

Pitfalls

• Trusting a remote party’s verbal assurance that it enforces the desired policies
• Sending passwords or other secrets across an unprotected network
• Accepting a certificate without validating the issuing CA and its signature
• Believing that a cryptographically protected channel also protects against a compromised remote endpoint

Minimum C11 · complete program · Download .c

#include <stdio.h>

int main(void) {
    puts("=== Toy Simulation of Certificate-Based Authentication ===");
    puts("Remote service ExampleCorp wants to prove its identity.");
    puts("It presents a certificate containing its public key, signed by TrustedCA.");
    puts("Local machine already holds TrustedCA's public key (pre-installed).");
    puts("Signature verification succeeds.");
    puts("Public key of ExampleCorp is now trusted for this session.");
    puts("Encrypted channel can be established.");
    puts("Remember: the remote OS itself may still be compromised.");
    return 0;
}

Compile locally

gcc -std=c11 -Wall -Wextra -Wpedantic -Werror ostep-57-distributed-security.c -o example && ./example

Expected result

=== Toy Simulation of Certificate-Based Authentication ===
Remote service ExampleCorp wants to prove its identity.
It presents a certificate containing its public key, signed by TrustedCA.
Local machine already holds TrustedCA's public key (pre-installed).
Signature verification succeeds.
Public key of ExampleCorp is now trusted for this session.
Encrypted channel can be established.
Remember: the remote OS itself may still be compromised.

CHECK YOUR UNDERSTANDING

Close the answer. Explain it.

Why do web sites typically authenticate themselves to users with a public-key certificate, while users authenticate themselves to the site with passwords?

Check the sources

• OSTEP chapter PDF

Drafts and official chapters change. The version mark is only the example’s minimum.