Building a (Really) Secure Cloud Product

The Product: MEGAchat What is Security? Infrastructure Trust/Authentication Protocols Client/Server Implementation
Building a (Really) Secure Cloud Product
Guest Lecture for
Master of Information Security and Digital Forensics
Guy Kloss
gk@mega.co.nz
Lead Software Developer
Mega Limited
30 March 2015
Guy Kloss | Building a (Really) Secure Cloud Product 1/36

Outline
1 The Product: MEGAchat
2 What is Security?
3 Infrastructure
4 Trust/Authentication
5 Protocols
6 Client/Server Implementation

Outline
2 What is Security?
3 Infrastructure
5 Protocols

The Product: MEGAchat
A Cloud-based internet chat system
Voice, Video and Text chat capable
Oﬀers multiple device capability for each participant
(transparent synchronisation, consistent view of chat)
To work in browser as well as native/mobile app

The Product: MEGAchat
Why “Really” Secure?
Everybody says they’re secure . . .
“Security Theatre” . . .
We’re doing it (we say) . . .
. . . and like to be conﬁrmed or disproven in it.
→ Bug bounty!
(for chat so far one paid out)

Security Theatre

Security Theatre
http://geekandpoke.typepad.com/geekandpoke/2009/12/security-theatre.html

Early Adopters

Outline
2 What is Security?
3 Infrastructure
5 Protocols

For the Chat System
Desired properties:
Conﬁdentiality
Identity authenticity
Message authenticity
Forward secrecy
Session freshness
Plausible deniability
Room participants consistency
Chat transcript consistency
Reducie foot print of “leaking” meta-data

Meta-Data?
c by Michael J. Swart
http://michaeljswart.com/2011/06/meta-aggregate/

Meta-Data?

Sparseness of Meta-Data
Don’t store what you don’t need
Then nobody can come and ask you to “comply”
If you must, do it so you can’t be compromised
(e. g. passwords, salted and hashed,
so not even you know them in plain)
→ Proper mechanisms for authentication
and password management/storage
On Mega
Most meta-data only known to customer (encrypted)
Company only knows what’s needed to manage
the platform and interactions

Crypto?
It’s really diﬃcult to get this right!
Avoid writing it, if you can!
Use oﬀ-the-shelf frameworks/helpers/packages
→ If you’re writing AES in your code,
you’re probably doing it wrong
If you can’t help it and have to build it yourself
Make the conceptual system not suck!
Make the implementation not suck!

Crypto?
The maths is good, it’s the implementation that sucks:
“No matter how strong the crypto was,
he attackers walked around it,”
– “Crypto Won’t Save You Either”, Peter Gutmann, 2014
http://regmedia.co.uk/2014/05/16/0955_peter_gutmann.pdf

Outline
2 What is Security?
3 Infrastructure
5 Protocols

Choice of System Components
Robust base OS
→ Security, maintenance, reliability
Many features are not necessarily important
Evaluate/select server (software) carefully
For required features
Go get rid of not required features
→ Security, maintenance, reliability
Is Cloud scalability a relevant factor?
→ Distribution, clustering, replication, . . .

Choice of System Components
(continued)
Prefer open source solutions
Auditable
Many eyes
Mostly more secure
If well maintained, usually very quick ﬁxes
(e. g. on security)

Secure System Setup
Shut down unneeded services
Configure systems securely
Turn off what’s not needed
Don’t log everything (production in debug mode?)
Get the SSL/TLS configuration right!
https://mozilla.github.io/server-side-tls/
ssl-config-generator/
Need bad examples?
https://httpswatch.nz/
https://httpswatch.com/
Use additional protection schems
CSP – Content Security Policy
HSTS – HTTP Strict Transport Security
CORS – Cross Origin Resource Sharing

Secure System Setup
SSL Labs Server Test
SSL Labs is your friend
https://www.ssllabs.com

Secure System Setup
Keep system upgraded (esp. security ﬁxes quickly),
short reaction times
Best one service per (virtual) host
(don’t slam them onto one host)
Use logﬁles with logrotation on a system level wisely
Allows for forensic analysis later
Without it, you’ve shut yourself out
from most root cause analysis
Stay on top of security things
This can be hard work!

(Automatic) Monitoring
Load (CPU, network I/O, memory, . . . )
Availability & functionality
Check for “odd behaviour”

Outline
2 What is Security?
3 Infrastructure
5 Protocols

System/Infrastructure Level
Always use HTTPS/SSL/TLS as a minimum
Too bad the whole CA system and SSL is a bit broken
And some of the ciphers/cipher suites “advertised”
for use are also broken
On the client side, always verify the full certificate chain
Many tools/implementations are lazy by default
(in Java, Python, C/C++, . . . )
Prefer to use certificate pinning
E. g. a mobile app for a known service
Recent Superfish scandal with Lenovo and others

Application Layer
User to server
Commonly username/password
Alternative:
Certificates, other authentication mechanisms
Too many concepts for secure authentication,
beyond the scope of this talk
User to user
Difficult if one can’t trust the platform/server
On Mega
Verification of user’s public (signing) key
via fingerprint comparison (out of band)
Authenticating further crypto keys
via signature by authenticated key pair

Avoid Security Warnings
“MRI Shows Our Brain Shuts Down
When We See Security Warnings on Computers”
http://ema-tech.blogspot.co.nz/2015/03/mri-shows-our-brain-shuts-down-when-we.html

Trust from the “Community”
Open source it!
Really!
Make the money with your service, not the code.
Why & What?
For peer review/audits
At least the core of the security-related stuﬀ
Really important for crypto!
Wouldn’t it be more secure if it was proprietary/closed?

Outline
2 What is Security?
3 Infrastructure
5 Protocols

The “Big Problem” (TM)
Use secured protocols
Nothing available to solve our problem
We had to “roll our own” . . .

Key Design Features of Chat Protocol
Group chat capable
(multiple “devices” of identities)
Outsiders can’t eavesdrop (decrypt)
New members only participate after “join”
Excluded members cannot decrypt any more

Anticipate what could go wrong!

Desired Security Properties
Confidentiality
→ Needs to be encrypted
Forward secrecy
→ Using (group) Diffie-Hellman with ephemeral key pairs
Identity authenticity
→ Sign some confirmation with identity key
Message authenticity
→ Sign messages with member’s session signing key
Session freshness
→ Use of nonces (to avoid replay attacks)

Desired Security Properties
Plausible deniability
→ Ephemeral signing keys for every individual session
(private key published at the end)
Room participants consistency
→ Key agreement requires participation of every member
Chat transcript consistency
→ Agreed and cryptographically enforced partial ordering
Reducing the foot print of “leaking” meta-data
→ Exponential message size padding

Outline
2 What is Security?
3 Infrastructure
5 Protocols

Do it right! Follow best practices . . .
Follow OWASP, that’s much more comprehensive
than this talk on this subject
Open Web Application Security Project
http://owasp.org

Questions?
Be Safe!
Guy Kloss
gk@mega.co.nz

Building a (Really) Secure Cloud Product

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Building a (Really) Secure Cloud Product

Similar to Building a (Really) Secure Cloud Product (20)

More from Guy K. Kloss

More from Guy K. Kloss (16)

Recently uploaded

Recently uploaded (20)

Building a (Really) Secure Cloud Product