08:59:29 #startmeeting secure, automated decryption 08:59:29 Meeting started Wed Aug 3 08:59:29 2016 UTC. The chair is bkm. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:59:29 Useful Commands: #action #agreed #halp #info #idea #link #topic. 08:59:29 The meeting name has been set to 'secure,_automated_decryption' 08:59:43 speaker Nathaniel McCallum 09:02:12 Principle software engineer at Redhat 09:03:00 How do we automate large scale encryption and decryption? 09:03:17 #topic Can we automate this? 09:03:29 Yes! 09:03:55 Use double encryption- innerkey for data and an outer key 09:04:16 User uses key encryption key 09:04:42 Distribute keys to people who need access to data 09:05:01 Standard escrow model for this appearing in standards 09:05:15 How protect transport layer? 09:05:50 USe TLS/GSSAPI 09:06:09 Use a third party authority as well 09:06:29 Backup data 09:06:46 Security challenges, eg Heartbleed 09:06:58 #topic lessons learned 09:07:07 complexity increases attack surface 09:07:13 difficult to deploy 09:07:19 speed matters 09:07:32 #topic can asymmetric crypto help 09:07:34 Yes 09:07:40 DEO model 09:07:53 Add a third layer of encryption for the key encryption key 09:08:26 Need to authenticate connections and protect channels 09:08:38 Asymmetric crypto makes server stateless 09:08:47 allows for offline provisioning 09:09:08 sending keys over wire risky 09:09:24 Hard to deploy, so stopped project 09:09:43 #topic 09:09:50 Can we avoid tls 09:10:56 Use wrap key and ephemeral key 09:11:12 Do not need to use TLS to send messages 09:11:45 Client keeps both keys, server does not. 09:11:58 Can use UDP. 09:12:11 Server only gets encrypted information. 09:12:29 Need to compromise client to get wrap key, not just server 09:12:36 avoids X.509 which is complicated 09:12:47 Can migrate to post quantum crypto 09:13:48 #topic Must the key go over the wire? Can clients be anonymous? 09:14:02 Consider Elgamal encryption 09:14:28 McCallum-Relyea exchange 09:14:39 Change decryption side of Elgamal encryption 09:15:23 Still need backups 09:15:53 Possibility of putting key in chip 09:16:02 Project Tang 09:16:17 #link https://github.com/latchset/tang 09:16:42 Server-side daemon 09:16:55 fast, small, minimal dependencies 09:17:47 #topic What else can we bind data to? 09:18:04 Trusted platform module 09:18:13 Bluetooth LE beacon 09:18:16 QR codes 09:18:23 fingerprint scans 09:18:59 Josh Bressers - security sliding scale of risk management 09:19:14 Consider Shamir secret sharing 09:19:48 Can nest this 09:20:08 An example is a corporate deployed laptop 09:21:15 Can automate process for users, eg. to decrypt disk automatically at work, but elsewhere need to enter password 09:22:30 Consider a high security system with 3 distinct passwords, for which 2 are required 09:23:28 As an example, complex laptop policy 09:23:37 LEvel 1 QR code 09:23:46 Level 2 TPM required 09:24:15 Level 3 need either Password, fingerprint, tang or bluetooth 09:26:08 Trying to match human behavior to make things more natural 09:26:41 #idea let business policy drive crypto policy and not the reverse 09:27:02 #link https://github.com/latchset/clevis 09:27:33 Project Clevis - minimal dependencies 09:27:40 early boot integration in progress 09:27:46 GNOME integration in progress 09:29:18 LIVE DEMO 09:30:22 #link https://github.com/latchset/TAN 09:30:34 Dependency JOSE 09:31:23 #link https://github.com/latchset/jose 09:31:44 #idea user friendly crypto 09:32:46 Good standard out of Microsoft 09:32:57 Dependency LUKSMETA 09:33:11 Store metadata in LUKSv1 header gap 09:33:33 #link https://github.com/latchset/luksmeta 09:33:41 C library 09:33:46 Command line utility 09:35:57 Name from binding for ancient handcuffs 09:36:01 #topic Questions 09:36:46 Easy to extend to distributed file system 09:37:48 LUX version 2 in planning, dedicated JSON storage area 09:39:17 EXT4 encryption, allows directory encryption to only allow a particular process to see unencrypted data 09:39:36 Can use this to deliver application specific keys 09:39:56 #endmeeting