Decentralized security
Securing communication in a peer-to-peer messaging middleware
24 September 2013
European Institute for Innovation and Technology
Eötvös Loránd University, Budapest, Hungary
Babeş-Bolyai University, Cluj-Napoca, Romania
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.
*Except the Skype protocol (proprietary)
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
HMAC(key, msg) = H(key ⊕ opad ‖ H(key ⊕ ipad‖msg))
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
European Institute for Innovation and Technology
Eötvös Loránd University, Budapest, Hungary
Babeş-Bolyai University, Cluj-Napoca, Romania