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