End to end encryption (and keeping data secure) in Elixir apps

With more and more focus on privacy, and new laws possibly coming in…

“The principle of confidentiality should apply to current and future means of communication, including calls, internet access, instant messaging applications, email, internet phone calls and personal messaging provided through social media,” said a draft proposal from the European Parliament’s Committee on Civil Liberties, Justice, and Home Affairs.

…what options do we have for end-to-end encryption in Elixir? Have we got anything like attr_encrypted for instance? How would you go about it in Elixir? Please share any tips/advice/further reading etc :slight_smile:

2 Likes

I am not quite clear what you mean here. End to end encryption means that the client is fully responsible for encryption/decryption. Unless elixir is the end-node it will simply be a carrier of encrypted traffic and there is not so much you can do except not trying to leak to much meta data. But “anonymousation” is a much harder problem than end to end.

Good reading material is any secure crypto protocols which claim end to end. Like the signal protocol (Start here: https://en.wikipedia.org/wiki/Signal_Protocol).

The provided link seems to be about encrypting data in the database which might be a good idea in some cases but also has little to do with end to end.

1 Like

Built-in in Erlang (based on OpenSSL), we have the :crypto module.

But as @cmkarlsson astutely stated: When you are building a server application in Elixir, the encryption and decryption needs to happen at the client-side. Only when you are making a command-line tool or a native GUI application in Elixir could you do the encryption/decryption in Elixir directly.

1 Like

Thanks both. I thought there might have been something additional required on the message delivery system/server/Elixir.

What about storing all user data securely (encrypted) on the server - in case the server is compromised? What if someone stole the server or hard-drives for instance?

Yes, this may be important. There are various layers that are normally used here (my terminology is probably off so don’t pay too much attention to it;)):

  • Data at rest. All data at rest should always be encrypted. This means disk encryption and encryption of backups for example. I guess some work here could be done in erlang/elixir with for example DETS storage.

  • Encryption on database. This is normally provided by the database software and usually entails encrypted connection between application server and database and on-disk encryption. The benefit here is that queries, joins and search are still possible/fast but it also has limited protection and only protects in the case someone gets access to the data files on the database. Data is in the clear in memory in both database (but can be restricted to some database users in for example oracle) and application server.

  • Appliation Data encryption. You can have the application server encrypt the data so that it protected even in memory in most circumstances. However if you decrypt in software the data will be in the clear in memory which again requires good protection of your actual server instance. I think your attr_encryption link earlier is an example of this and they also state the drawbacks such as you can’t index, search or join data from the database. Unless you have a secure core for handling unencrypted data I think this is not worth it. Too many inconveniences for too little benefit.

For extra sensitive data you can use an HSM (hardware security module) which generate and encrypts and decrypts data. Data is only in the clear in the HSM and of course the client can also decrypt it. For high levels security you need hardware support both on the client and server. Like secure chipset, factory bootstrapped certificates and HSMs.

It is hard to get to “criminal enterprise” security and “nation state” is probably impossible.

In practice: Just don’t be the weakest link ;), eliminate all the “easy” access points

For erlang and elixir, you need to make sure you use secure connections (SSL) in and out of the server and make sure that the server is hardened, you may want to avoid distributed erlang (although I don’t have a rational for this but it seems like it could open up some attack surface).

If someone gets physical access (or even remote access) to the server it is very hard to protect your data. That is why end-to-end encryption is important. You cannot guarantee your data if it is in the clear anywhere between the two end-nodes. And unless you are really sure that you don’t have any MITM (man-in-the-middle) attacks during key exchange you can’t really be sure anyway :slight_smile:

You can play around with your own security protocols but it is full of hard things to solve that you normally don’t think about. My go to example is using a short-circuiting comparision for an Message Hash. Because it takes shorter time to compare a “broken” hash than a correct one you are open to timing attacks which may be able to compromise your protocol.

3 Likes

If the client is a web browser, isn’t end to end encryption a fiction? If the user executes javascript then a compromised server can send (and force the browser to execute) any malicious script. If the user doesn’t execute javascript, how will the decription happen?

If you have a client that doesn’t execute serverside code, then end-to-end encryption is of course useful.

2 Likes

Yes, this has historically been the problem with javascript security. Mostly because of delivery problems. If you can deliver the scripts in a secure way you can potentially have some security.

For example shipping javascript bundled with your application which is distributed through a secure channel (are app stored secure?)

1 Like

That seems as safe as it can be. You need to assume that the app download is secure and the user never upgrades (otherwise the upgrades need to be secured). If you can’t assume this, then nothing is secure :stuck_out_tongue:

I think the problem with app stores is that they can probably make funky stuff with your code without the user noticing if they want. I know nothing about mobile development, so I don’t know how easy it is to check that the binary downloaded to the phone is the same as the one you compile yourself. This is probably overly paranoid for most atfack vectors, of course.

1 Like

Thanks for the informative post Martin :023: I think the quoted bit above is what concerns me most - most of us don’t have the luxury of having our own data centres and I would imagine it would be relatively easy to get access to someone’s servers in one of the commercial providers.

I definitely need to read up some more on this!

1 Like

If I need end-to-end I just PGP my message, which can serve a variety of purposes, like:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I can sign my messages, which proves I am who I say I am (if you have my public key or grab it from one of the online distributors).
-----BEGIN PGP SIGNATURE-----
Version: OpenPGP v2.0.72

wsFcBAABCgAGBQJZST73AAoJEDq33FO2mThAr30P/21AccdhkF9vVXS9jwXrftap
jO+Rkj0bzEVL0AqfaomiXdR9n89tKUJe1P0G6lIeKWYGKV04moRCX6TC9BenLFSK
lKm1ezY5AQK1GU+eDfvJuWqL7syLg9KXWqpKqamhz9UkNH83ipPnA0LsqhtX5O+F
QwuKrmYAnGDv4fttZk++wjk4v+iDk5Bwl7qitNcVW/eck+ntU0L8vSQqc9kEGrI6
PLfrMhFU1weXlpiJ5psmClG1AtqY6SJGZKrgDEE9yn2oVqZSunfYgTHoYgx5l0Mf
LYhc83YukcwndFpaYkcwLGrgT/tJmZT/1i2PxZComx9+FEpoqKes8WWwlEJbD9RZ
ELcj3QTrf6T/oGeRYXCqcjd68mMz4+RBH4GHIxAkgK7/nqDLbLY5Lbl1rgCborC5
S049CWGlX2J/Ny2KIeODgSrFRSTa31oIYYYUbWvSI5wnn58neKxbaxmLwBW2u8wB
xTOh51ZoG5/AjH9amvYSGH8A/0YRrwdByD48hc132W5wGUcXjwS64ZA7MUVfS4ub
nzG8nHMBXRp/oiTlwdIn1wClFGaHRyNeG/N2u5Qye/lcEkF1g0QfZong1Mtl3YEK
cbyZABn3fGW+5Ab7VfCD6SqtrNCMi5Bm27umc9m2PF/tRmbzThB9ZMl2zAmHmlQD
u1MB0XKTF64FQmG3f4OG
=Hfy/
-----END PGP SIGNATURE-----

Or I can encrypt a message to someone (in this case to my public key), and I can sign that encypted message too that way they know it is absolutely from me and I know that only they can read it:

-----BEGIN PGP MESSAGE-----
Version: OpenPGP v2.0.72

wcFMAxHD5uENN/acARAAyeQ95aTq6+wM9rjcbXJZ7eCHvbUKAbJ91ImA8PDiB4EV
NwTFUaMl5wEX2RrgitlvicbPAqx9Jvj6TReKIsws3k81CORN4jo1v27dlV2Zj5IE
mo6EelfJ0WGwkIefaCUzKpxAfVZjWYraZJaQsCXSI2iZHG/7jo1VgpElkhUtuYhk
+XfV7JcWy+5uIFLlAg1quRs+4AG+MYQfUREq6no4ydwqrXov2jg0S7gRIzHlw/0O
aqJ0T4jQ7M3q8r07IBO20vCx9YbAlF2iIlfJ49b+paITTN+nGTX06x1dJRKINcsw
wpg5Zx2ctl6l57Gy+P7clw6GSYab2zrh9FjfRVFXuHbBNBiJms6y+kuw7HPWNwjP
Sgucr7LNabkVP0lDvbcC09kpJSyT3U2K3mqv3QqYwaOCjNZitpikRW8zgt69/SkJ
ZJ1hJOEs1JQbijhSzhhEUqiY7ThQiNiOO6r20y7nPXbqLZmL5sO+mYD3tHqpKR+U
XDkgBhJcA90nyLmkUWwIfyf0sYHuUKIdZvefYyWdwnhPm+EcntZiFCiUZUfSQrv9
S1Ubw19Bx58613SROQAwbSYimVosOG3ygcOxl39AgDdD6XTQh5rWPUOz6hgGbSqZ
b30JOaY499hwcfTDA2d/zcpsYBQBWgWe61xE+drE6XlE3sA4NTEqyl1KT02XBR/B
wUwDEcPm4Q039pwBD/9MMsFTt1YXB1RpNycBIFXnRbwfecKDH3/Y/q0RRm3NYQep
JZ78nUfEY0KmD5Y6e7d7hZvEA+n3ghRS9pEEdSvTacmXwNSOoQ0nK5oXl6jCVq1F
gt6KPVc9QvXfVxZx5L74nKChNoGHtzXRWSLjpMYiGEjI+OisFI4FsqfcwRL2CFFj
mCtHVnRX+2oQrtvDwCsVqJNpyp75ifvpW98ibQQJmXmvvfU9DWM3YWSwllkW7NBk
wPOPxiueEwOTZrg38gpCMg2CyjYe6Jvsim6sS2HjshQyxJQksW5uCk0pBt9fYisy
9MEQ0p62fpzeMMukpLrCwlY6vRra4MSTxuT9MxBsgWsqLAXiBb9hX+mT+cd++chX
pwlMTQYAyzO8wN4sBFCiVwkZ4q/AAoLEicE3KwGDA7/QHgdWGRtQZ5ioxFIjTdxO
Z0LwM5NCVKiJpMMwtV4mM3krhaZttEp+CzXm6/vo1rfnNUkXLNgxQmVwmUXguv1t
Loo51J8/t5h7cAIXNb2nzWn3Y5TK+V3VGSMmMn3NmQZ1UyEC8rgy2b5/m81UBuXN
M45ldZAyPNGaLUe+NMldAz3KQfuQEu07+sEkefw+TlEQyivLblPmfxI2ldfbY3mI
4nrpxA+QaRui2RvbXmDL/a3iqbmzNEEX4n+gFibYsFraDWx3tyINd6ZM5WfFVdLB
xwH/npgPPWpdxuuHyfUc6jqWTIHdMJbJKK4/N3HiV/jSAziQrmhZ0ztyMlPTYsnT
oMJ30MnqeF3dhF3nP/Y9RJb6PNhZwATu2dky1uQXlsWE2br/A2IIHsmr8TzaCnzP
+TUWpArYmb4x4dZ/TtqetoDpGEKBStJfnNzat5oHDEZgqAGVc/5wBIdPTdqr4/I0
BqOB78QreMF7CaFQ/QjMnAa8ImsxVazVa029mvHciJSR7m73dF+HLVXpW9YPGTfm
rXGi+fpz8DzEMjbRItgNfxXSQUigQ1P5B3ADu22LCHCLwVnYk5g96mTCpgau3Hxv
0buyJY4GpM6Wzsp92koARvF6KAbpo1XLQctCA8nNWf0S9Mw0HBZtoTC0E82cPlSJ
SKb4Mt3MRrF0sMc170fZt3kS/W2WKdqcngv0dSMkyU01kRPUqgOmHzPAB3pDZbTc
pl5LPC+D37m7pHKdFe6TBu9RkxlE13WPrTtrGwl+l9Ksxc1bgsts9gDfsOo5Ppd0
VLFoUky1B7U1zc6UQzNsfcPOWycg4bE7XbGQIbCVMoEM0X35YJVwj/qfQZz8iQnA
n7cFty/uYGjRkBGezemPyepS8G0NKNgNh+6a8D0/ekcEAGDPplyii8Q7NQs2aC22
6Qrmzatx5nQgJZ9yKssQVAQqU9hUaqHXm8eLB48GhYRFlYWGg9w2C6X8Rj8F47bc
o3exAeXFA9w9Oz9+IlBsKsON34ZgHWgmuIQSfcMf5ChCXfccMV8aQhwrcN0e8tAN
NUbAvJfZ+RJCAUZnrcQUw6Rlq9mWs53zQ1vrYn9KXFpGMQ8AaBNC1LI+Gy/W0h+X
NLxFvlzOHuiEFsN+KQkc24V4ton7zQhQ
=QuOe
-----END PGP MESSAGE-----

And since it is all just text I can send it anywhere, here, email, etc… :slight_smile:

1 Like

I’m on about securing user data in our apps - user’s don’t want to be bogged down with complicated steps ^^ :stuck_out_tongue: - they just want to sign up to a service/social network then make a post and expect it to be safe :lol:

Well you could use the Keybase messenger, it uses your local PGP keys and users public keys to send messages between everyone, fully secure and built on known standards instead of weird new things. :wink:

1 Like