Building a (Really) Secure Cloud Product

The Product: MEGAchat What is Security? Infrastructure Trust/Authentication Protocols Client/Server Implementation

Building a (Really) Secure Cloud ProductGuest Lecture for

Master of Information Security and Digital Forensics

Guy Kloss

[email protected] Software Developer

Mega Limited

30 March 2015

Guy Kloss | Building a (Really) Secure Cloud Product 1/36

[email protected]


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 systemVoice, Video and Text chat capableOffers multiple device capability for each participant(transparent synchronisation, consistent view of chat)To work in browser as well as native/mobile app



The Product: MEGAchatWhy “Really” Secure?

Everybody says they’re secure . . .“Security Theatre” . . .We’re doing it (we say) . . .. . . and like to be confirmed 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


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:ConfidentialityIdentity authenticityMessage authenticityForward secrecySession freshnessPlausible deniabilityRoom participants consistencyChat transcript consistencyReducie foot print of “leaking” meta-data



Meta-Data?

c© by Michael J. Swarthttp://michaeljswart.com/2011/06/meta-aggregate/


http://michaeljswart.com/2011/06/meta-aggregate/


Meta-Data?



Sparseness of Meta-Data

Don’t store what you don’t needThen 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 authenticationand password management/storageOn Mega

Most meta-data only known to customer (encrypted)Company only knows what’s needed to managethe platform and interactions



Crypto?

It’s really difficult to get this right!Avoid writing it, if you can!Use off-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 yourselfMake 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, 2014http://regmedia.co.uk/2014/05/16/0955_peter_gutmann.pdf


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 importantEvaluate/select server (software) carefully

For required featuresGo 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 solutionsAuditableMany eyesMostly more secureIf well maintained, usually very quick fixes(e. g. on security)



Secure System Setup

Shut down unneeded servicesConfigure systems securely

Turn off what’s not neededDon’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 schemsCSP – Content Security PolicyHSTS – HTTP Strict Transport SecurityCORS – Cross Origin Resource Sharing


https://mozilla.github.io/server-side-tls/ssl-config-generator/

https://mozilla.github.io/server-side-tls/ssl-config-generator/

https://httpswatch.nz/

https://httpswatch.com/


Secure System SetupSSL Labs Server Test

SSL Labs is your friendhttps://www.ssllabs.com


https://www.ssllabs.com


Secure System Setup

Keep system upgraded (esp. security fixes quickly),short reaction timesBest one service per (virtual) host(don’t slam them onto one host)Use logfiles with logrotation on a system level wisely

Allows for forensic analysis laterWithout it, you’ve shut yourself outfrom most root cause analysis

Stay on top of security thingsThis can be hard work!



(Automatic) Monitoring

Load (CPU, network I/O, memory, . . . )Availability & functionalityCheck for “odd behaviour”



Outline


2 What is Security?

3 Infrastructure


5 Protocols




System/Infrastructure Level

Always use HTTPS/SSL/TLS as a minimumToo bad the whole CA system and SSL is a bit brokenAnd some of the ciphers/cipher suites “advertised”for use are also brokenOn 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 pinningE. g. a mobile app for a known serviceRecent Superfish scandal with Lenovo and others



Application Layer

User to serverCommonly username/passwordAlternative:Certificates, other authentication mechanismsToo many concepts for secure authentication,beyond the scope of this talk

User to userDifficult if one can’t trust the platform/server

On MegaVerification of user’s public (signing) keyvia fingerprint comparison (out of band)Authenticating further crypto keysvia signature by authenticated key pair



Avoid Security Warnings

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


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/auditsAt least the core of the security-related stuffReally 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 protocolsNothing available to solve our problemWe 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 comprehensivethan this talk on this subjectOpen Web Application Security Projecthttp://owasp.org


http://owasp.org


Questions?

Be Safe!Guy [email protected]


[email protected]

Internet

Building a (Really) Secure Cloud Product