Decentralized security

Securing communication in a peer-to-peer messaging middleware

24 September 2013

Note, these are the offline slides of the presentation. For executable codes, please check playground availability at http://iris.karalabe.com/talks.

Scenario

Peer-to-peer based messaging middleware for backend decentralization.

Why peer-to-peer? Prevalent MOMs:

• [ AMQP ] Central broker – Simple, secure, unscalable
• [ ØMQ ] Socket queueing – Scalable, (in)secure, complex

Security

Unintelligible transmission with a verifiable originator and unhideable tampering.

Peer-to-peer "security" in the literature*:

• [ Castro+ ] Routing key limitation – reduce malicious access
• [ Wang+ ] Use physical topology – not applicable in virtualized environments
• [ Gheorghe+ ] P2P streaming – mitigate malicious effects

Conceptual mismatch: correct functionality in the presence of malicious nodes.

Environment and threat model

Operational environment (compute cloud):

• Private and firewalled network
• Malicious entities within, but not on hosts
• Links span untrusted networks

Possible attack vectors:

• Sniffing attack – Information extraction from captured packets
• Spoofing attack – Unauthorized access or entity impersonation
• Replay attack – Operation duplication due to packet resends
• Alteration attack – Data change through packet modification

Unit of security

Overlay network of – possibly different – instances, that collectively provide some service to outside entities, where all members within the same network are trusted.

• All service members trust each other
• Services use global asymmetric keys

Handshake – Establish master key

[ Diffie+ ] Station-to-station key exchange (STS)

• Requires pre-shared public keys, cyclic group and generator
• Establishes shared secret key with two way explicit key confirmation

Handshake – Derive operation keys

[ Krawczyk+ ] HMAC based extract-and-expand key derivation function (HKDF)

• Requires pre-shared salt and info, pre-established master keying material
• Derives 255 × <hash size> secure bytes

Transmission

[ NIST ] Encryption – Advanced encryption standard (AES)

• Requires pre-derived key and counter, encrypts with counter mode (CTR)

[ Bellare+] Authetication – Hash-based message authentication code (HMAC)

• Requires pre-derived key, generates the MAC of the ciphertext

Point-to-point encryption

Secure against all identified threats:

• Sniffing attack – Symmetric key cryptography
• Spoofing attack – Asymmetric key cryptography
• Replay attack – Counter mode stream cipher
• Alteration attack – Authenticated messages

Expensive re-crypts during P2P transit

Optimal point-to-point encryption

Forwarding nodes don't need the data! Why decrypt it?

• Separate message into headers and payload
• Encrypt payload with temporary key, insert into header
• Transfer header using point-to-point encryption

Only endpoints process the full payload! How much better?

Performance evaluation

Throughput comparison:

• Small messages – Temporary key causes extra payload + point-to-point crypto
• Large messages – Minimum overhead outweighed by reduced crypto costs

Verdict: if ‖message‖ < 4096 bytes use PPE, otherwise OPPE.

Thank you