 I'll go ahead and get started now. This is a multi-factor authentication for the cloud. My name is Dustin Kirkland. I'm the CTO at Gazang. I used to be self-conscious about this first slide, but it turns out many people haven't heard of Gazang yet, so I'll go ahead and leave with it. We're a small startup based in Austin, Texas. Venture funded. We're focused specifically on encryption and key management of what originally was for the cloud, but it turns out there's quite a bit of opportunity now around big data. The more data that there is out there, the more often we see private information that needs to be secured and keys managed for it. We have packaged solutions protecting Hadoop, Cassandra, MongoDB, OpenStack, a number of other different big data and cloud platforms. But for the most part, we can run on any Linux distribution. We are active in various open source communities. We're a new member of the Linux Foundation. And what we're ultimately doing, we're helping our customers secure their most sensitive data at RAS. So first of all, authentication. Before we talk about multi-factor authentication, let's talk about authentication. It's most basic. It's really the act of confirming the identity of purported by a person, or in software terms, often a program, by using something that it has, knows, is, or does. From a has perspective, we're all familiar with showing our ID or our passport at the airport or at the DMV. That's something that you have. You have this credential that supposedly there's only one of, that it's hard to fake. It was issued by a trusted authority. From a software perspective, that might be a token or a certificate, a private certificate. Something that someone or something knows is the traditional passphrase or pen or the pattern used to swipe on your phone. There's two other forms of authentication that's often used. Something that someone is or does. I'm not gonna talk about those here, really. That's not very cloudy. It's very difficult for a program to simulate or have a fingerprint or DNA or a retina. Really, that just comes down to being a private certificate or a private passphrase. The same goes for does, a challenge response or spoken pattern. Moreover, and this is maybe a personal, more of a personal opinion, but I really don't think that fingerprints or DNA or retinal scans are very good forms of authentication. This is just a small tangent to the side, but for me, it's very important that the piece of information you're using to confirm your identity is something that can be changed and rotated. Should your fingerprints become compromised, it's very difficult, if not impossible to change your fingerprints or your retina. Moreover, your fingerprints are all over the place. My fingerprints are on this glass right now. I don't do that with my passphrase. I tend to think of a fingerprint or a retina. That's more of a username, not a password, right? Perhaps willing to share, much as I'm willing to share my fingerprints on this glass, my username, but that's not enough to uniquely identify a person. So this says that, and aside from the current discussion, think real hard before you introduce biometrics into an authentication system. So that's basic authentication. What about multi-factor authentication? How and why is it different? You may also hear this called two-factor authentication. I prefer to call it multi-factor authentication because it can be any combination of the has and knows and is and does. It can be any number of things. It can be multiple has that are required. It can be some combination of has and knows. I also often shorten it to multi-factor off because there is, as we'll get to in the end, a bit of a difference between multi-factor authentication and multi-factor authorization. And that's two very different acts. So the goal with multi-factor off is to significantly reduce the risk of authenticating a false identity, a false entity, someone or something purporting to be the identity that it's trying to authenticate into. And it does this by increasing, vastly increasing, if you use these inappropriate combinations, increasing the landscape of resources that have to be compromised in order to perform that authentication by a false entity, while still making it possible for the true entity to be able to authenticate. The images here have the fingerprint and the retinal scanner. As mentioned previously, maybe not the best idea, but when using combination with other things, it can really increase the amount of effort your attacker might need to spend in trying to falsify that authentication. If you've seen Mission Impossible, Tom Cruise's character, Ethan Hunt, goes through more than a little bit of effort to break into the CIA and log in with the five-character password. Which is always amusing to watch in retrospect. So when is multi-factor off in the cloud, as is the topic of this discussion, when is it essential? There's a lot of places where I'd argue that it's important or essential in our organization and in many of the organizations that are our customers or partners. It tends to be in mission-critical and production systems, especially when the data that is being guarded is private or in a regulated environment. Quite often that's in government, healthcare, financial, or even academic. There are laws that protect the records of minors, especially in student records. And then I would say essential in internet-facing systems. We think about, I've been in Linux security for over a decade and some of that time has been spent in CIS admin roles and we spent all the vast amounts of effort that we put into keeping machines from being internet-facing, keeping those systems from being on the edge and being able to open up ports on internet. And now for 10 cents an hour and within the next 30 seconds you can have dozens of them with public IP addresses and ports open all over. So think real hard about multi-factor off in internet-facing environments. Multi-factor authentication is already supported by a number of popular services. Just to mention a couple, this is hardly a comprehensive list and I'll get into a bit more specific. And some of these can be argued how cloud are they, but that's just the ubiquity and the breadth of the term cloud now. Certainly Amazon, AWS, there's a multi-factor authentication feature. You can enable this and then hook up Google Authenticator or Jim Malto or RSA key to your AWS account or accounts in many cases. Those are required for production systems. That can guard the access to the web console, launching of systems, other privileged operations. The Google Authenticator is also very popular, easy to use with Google services. It's not very difficult to set up. It does impact your user experience. I'll warn you. Having to have your phone up and running and hooked up to Google Authenticator every time you do something that requires authentication with Google, it's unbelievable how many times per day that might come up. It's also really inconvenient when you reinstall Cyanogen on your phone and you dropped your Google Authenticator token. It's a bit of a manual process to reset that appropriately. And for a good reason, obviously. There's always a sliding scale with security. There's a hyper secure but very difficult to use and then there's extremely usable but lacking all security. You need to find the place on the dial that makes the most sense for a given environment. Dropbox has what they call, I tried to use the terms that each of these, if you were to search for any of these, the terms that these companies use for their multi-factor authentication. But Dropbox has a two-factor verification feature where access to certain files or objects in Dropbox can be verified. Same with PayPal, you can actually order a physical security key. It's another one of these, I'm not sure who makes it, maybe Jamalto makes the physical security key that gets used that is required to use your PayPal or eBay account. And then Facebook recently implemented login approvals for certain, you can set up your account to require you to approve a login using SMS, which is perhaps better than nothing but SMS has its own security issues and considerations. Probably the most popular, the most well-known is the time-based one-time passwords, OTPs as they're often called. Rolling tokens is maybe another word for it. It's actually extremely simple to implement in its most basic form. This is three lines of shell code that will very quickly and conveniently implement a, it's a character missing on, got pushed to the next line there. I'm gonna scale this to 10.24. This is a real simple example how to do a time-based one-time password. Take a shared secret, you gotta get this shared secret on the two different places. You choose it sometimes, it's given to you other times. You take a time stamp. This is a real basic Unix Epoch time stamp number of seconds since January 1st, 1970. We're gonna take the first nine digits of that, leave off the last one, which will give us basically a 10-second one-time passphrase. So that changes every 10 seconds, this is decimal. And then you concatenate that shared secret with that time stamp, perhaps run it through an HMAC and then I grab the first six characters from it. That's extremely similar to what these dedicated devices are doing. All of them require a shared secret. They require some amount of time-based synchronization. Now, for far more resilient and robust algorithms, have a look at these internet RFCs. The original one was 42.26 and HMAC-based one. A much more modern one is 62.38, which is what their Google authenticator is based on. They're a bit more robust. They handle time drift, as you can imagine, requiring two servers to be in, or two systems to be in perfect sync. It gets difficult over time. So they have a way of basically resynchronizing itself and determining how far out of sync they are. And a couple of, not that I'm endorsing any of these products, I just stole their images off the internet, but the classic RSA secure ID, Jamalco, Authy has a real interesting app and a very small bit of shell code that you can put in your SSH config command and require an Authy code every time you SSH into a system. And then, of course, the Google authenticator. So when can you use multi-factor authentication? Fundamentally, in a Linux system, anywhere in the PAM stack, take a look at cpam.d and you'll see a number of different places that we've already hooked in Linux and within the authentication system that require or define as sufficient different pieces of information. Linux is set up very well for multi-factor off and has been for decades. And some people have used it for decades. But simple cases at login, desktop, or console, or SSH, it can be any one or all of those three. At something like a password change event that also goes through the PAM stack. And then administrative tasks, such as sudo or call on or at jobs. Within the last year or so, Ubuntu implemented multi-factor authentication through the Google Authenticator. You can very easily set up either a desktop or a server to use the Google Authenticator where in addition to providing, first you provide your password and then you have to provide the token that you get from the Google Authenticator. And that works just as well on Ubuntu servers. It's actually pretty simple to set up for any Linux system that supports PAM. So when is a multi-factor difficult? Well, it's reasonably straightforward when the authenticating entity is a human, right? And all of these examples we've shown the rolling tokens or some piece of hardware, a smart card or something that someone has, right? And we know how to do that. We've been doing that for a while. It can actually be a bit more difficult when the entity is another program or a process or something else that's also in the cloud. So especially with the cloud, we're talking about automated processes and we're talking about virtual machines where there's machine communication and often these are virtual machines and especially in between services. So I'm sure we've all seen the snippet of PHP or Python or Ruby code in a web app that has a password that's embedded in the code somewhere and then passed in a connection screen. I mean, that's the way we do things. If not that, then it's in a file and we open that file, read it and put it in there. But fundamentally that password lives on disk somewhere and has to be loaded into memory. And that is what it takes to connect to MySQL. Perhaps that's the MySQL server has some firewalling on it that requires an IP address for whitelist hopefully it's behind a VPC and there are some additional levels of protection. But the piece of authentication itself ultimately is password. Of course, we use extensively in cloud computing, SSH and SSL or hopefully we use extensively in cloud computing, SSH and SSL. But fundamentally there's a private key that stored somewhere that is used by SSH in this case in an R-sync job that at 4 a.m. every morning copies the logs off from this system to a backup system. It's authenticated using that private key and only that private key, that's a single factory. It is strong encryption. This could be an RSA key 4K long. You could use a strong algorithm but there's still only a single bit of information that is required to perform that authentication. The lower example, that's a snippet of an Apache configuration where there's an SSL certificate, that's again a file on disk, a private file on disk that's required to host that Apache service. A single authentication is required to start, excuse me, that single file is what's used to start Apache and SSL. So I'd like to introduce a bit of a different concept here and it's a concept that we call, we know in modern terms as a trustee. I can overhear a little bit of a conversation next door and this guy evidently is an IP lawyer so he could probably do a better job explaining a trustee but a trustee is a legal term. It's a person or an entity who has a position of responsibility to act on behalf or as an authority for others. There's a lot of ways we can think about this but at its most basic in a modern democracy we elect leaders who make decisions on our behalf. We don't always agree with them. Perhaps we agree with them less than we would like to but ultimately we're entrusting them to vote on our behalf and that's the US Congress in this case. But where does the term come from? The concept of a trustee as a voter was formulated by this guy, Edmund Burke. He was a member of British Parliament in the 18th century. He was also a philosopher and he wrote extensively about British politics and about just the philosophy of acting on behalf of others but the modern term of a trustee being used in the sense of a voter comes from this quote. Essentially it's someone, typically someone, we're gonna talk about it as something, a computer program but it's someone that considers an issue and after hearing all the sides of the debate exercises their own judgment and makes the decisions about what should be done in that case. So thank you, Mr. Burke. But trustees, we also know from a different term and we know trustees from a sense of a trust fund. The modern concept of a trust fund for property is actually much older than the concept of a trust fund from the sense of voting. It actually developed in 12th century England. So once again, thank you England. Here, you're welcome. Sorry, appreciate it, much appreciate it. Yes, absolutely. In 12th century England, during the Crusades, landowners, especially wealthy landowners, they would leave their property in the care of a trustee so that when they left to fight in the Crusades, this trustee didn't own their property but it was up to them to essentially bestow their will or exercise their will passing it on to their beneficiaries, their children. There's actually kind of a funny scene at the beginning of Robin Hood, Men and Tights, the Mel Brooks movie, which I debated. Mel Brooks or Paris and Nicole, they won. But in the beginning of Robin Hood, Men and Tights, Robin Hood, Kerry always comes back from the Crusades and they're hauling off his castle and it had been entrusted in the wall. It's a comedy, so it wasn't properly executed. But the concept of a trustee in this sense is someone who acts, like voting, acts on behalf of the property that they're entrusted with. They don't own it, it's not theirs, but it's up to them to make decisions as if with the beneficiaries' interest at heart. So let's take these concepts and fundamentally apply that to software, to a software system. So within, this is the product from Kazang. We essentially have two products. One's an encryption product, the other one's a key management product. The real differentiator in our key management product is we've taken this concept of a trustee and trustee voting and formulated that in terms of software. We've brought that and we're using that both for authentication and for authorization. This enables a system administrator to delegate the approval of the release of information to one or more trustees. That release of information could take any form. We treat it as an opaque object. It's encrypted in a way that we actually are true to the trustee concept. We encrypt that data using the beneficiaries' public key so that only the beneficiaries' private key can decrypt it. Not even the trustee can see the information that's being entrusted to the Z-Trustee server and either the server, the one holding it, nor the trustee is privy to that information. What the trustee is allowed and unable to do is decide whether or not that information should be released. So in practical terms, once again, we're talking about passwords or passphrases, private certificates, private keys. One-time passphrases or tokens, perhaps generated objects. It can be files, and if it can be files, it can be tar balls. It can be collections of information. There's a couple of bits of vocabulary we use when we talk about this. One is a client. The client is the piece of software that actually puts a deposit onto, we call them deposits. We try to use banking terms wherever possible. It's the client that puts the deposit into the Z-Trustee server. When it does that, it actually, at that time, because it had access to that information at some point in time, that point in time, it defines the policies by which it can be released. And we support all the normal things you get out of a KMIF or a typical key server such as a TTL on the key, a limit to the number of times it can be retrieved. But we've also added this concept of trustees where when putting the deposit, the client can define, well, zero, and there are no trustees, but all the way up to n number of trustees. And those trustees can be humans or they can even be programs. You can identify a trustee by an email address or by a GPG public fingerprint. Question? Good question. It's, in every case I've ever seen, it's data. It's strings, it's files. It's something that we can encrypt and base 64 encode and insert into a database somewhere. I've never thought about it from a runtime sense. Interesting. What would guard whether you can do that or not? Is it some bit of secret information that allows you to do that? Sure, that's a good question. I'm intrigued. I don't think I quite see the connection yet, but I would like to talk about it more. So emails are the request to that email address. We can actually sign and encrypt the message to that email address. We always sign the message. If we have that email address in a production system where this is your system administrator, people have GPG keys that have been uploaded to the server, we actually encrypt that message and all messages when we have a public key on file to that address. And so we'll throw it out there, but only the person with that private key can encrypt it. Actually, both are supported. So the ideal use case is we have public keys for everyone. We actually have a public key server that's part of ZU trustee. We started with the Debian SPS, which is the synchronizing key server for PGP. We hit the limitations of that because we're running this in environments that may involve hundreds of thousands, millions of clients, and scaling that SPS didn't work. So we're actually working on a GPLv3 replacement for SKS called HOPIPOP, or HPP. So there is a public key server component to this that's required for all client-to-client communications. Every message between a client and a server, the programmatic sense, is signed and encrypted using GPG. That's how we do the authentication from the clients to servers and servers to clients. But in the case where that's not available, we've also got a URL not space approach where, much like, say, the Facebook approach to, we'll just click on this link in this email. We do have time-expiring, one-time-used, not URL links where there are organizations that, GPG is frankly hard to set up and hard to get working. So both are supported by default, everything signed and encrypted. Unless we can't do that, we fall back. Does that answer your question? So that trustee would, in the case where the not slink is used, they would need to know the Z-trustee server name and they would need to guess or somehow intercept a 256-bit randomly chosen nots. If it's clear text email, that would be possible to scrape. If it's encrypted email, impossible to scrape. If you're not using the email-based approach and I'll get to the different trustee interfaces in a second, then it's as impossible as brute, or it's as difficult as brute forcing a 256-bit nots. That's actually, that's certainly not the optimal way to do it. We've got APIs in, yeah, I'll show you in just a second. We've got APIs in Shell, Python, Java, and C and all of those are over SSL links, number one, to prevent man in the middle. Number two, you go through that API and it will form a, let's see, the innermost packet is a bit of JSON, JSON contextual information act on this, it's a REST-based approach. That JSON is then signed by that client's public key, sorry, private key, and then encrypted to the server's public key. So now we've got this encrypted signed blob of JSON data that is posted to the ZTrustee server. The ZTrustee server decrypts that data, only the server with the private key can decrypt that data. It checks the signature and using that signature check, it determines which client sent this information and then cracks open the JSON and performs whatever action is specified by that. It then concocts a response. That response is then signed by that server's private key and then encrypted to the client's public key. And then that goes back over to that client in SSL. There is that double encryption there and this is, it can be a CPU intensive of work, but that can certainly be mitigated. Does that help? Both, both are doing it. The client and the server are both using fundamentally GPG. That's all right, no, it's a good question. So clients later request that deposit. The client must be able to meet all of the defined policy, the server enforces that and the trustees are probably the most, certainly the most flexible and extensible policy of all of them. The basic policies are the ones required by something like the KMAP, the Key Management Interoperability Protocol. But the trustee can be anything that you could possibly imagine requiring. So in a programmatic or, I'm sorry, in a pictorial form it looks like this, that it's the clients here, one or more clients that are putting and getting this data to one or more Z-Trustee servers. That Z-Trustee server decides if it can, that client can meet all the policies defined for that particular deposit. And if that particular deposit requires trustees to vote, the requests are sent out or made available for these trustees to then vote on up or down and if that can be met, then that deposit's released back to the client. So in the GPG case, this is an example of the decrypted GPG message. It still has the signature here at the bottom. But in, okay, in this case, so this message is a cryptographically signed message. It says, hey, this is your Z-Trustee server. A managed client has authenticated itself, so that much you have to trust that the server has done a good job of authenticating the client and has requested the following deposit and it has this handle in this description. That's just metadata that the client set whenever it created the deposit. It provided the following explanation of this request and this is a free form field that the client when making the request can define and this is called a justification and this justification could just be basic information. It could also include some sort of a challenge response or some other additional bit of information. In this case, inside of this encrypted signed email are two Naut's links and these are, when I said Naut's links, that's quickly what it looks like and you've got all the usual limitations of a get-based URL, but all the advantages of a get-based URL. And one of these is an authorize, a thumbs up, another one is a deny, thumbs down and each of these links can only be used one time. Question? Yes, absolutely. And this is a snapshot of the previous version. I took this from the previous version. We now identify the client. We also include the host name, my key address, internal and external of the client and put that in this message. So hopefully that's a little bit better if you've got other ideas. Yeah, we certainly can identify this client by its public fingerprint as well. I'll take a mental note to add that to the metadata that comes back about the message. But yeah, I'd love to hear your ideas. So that's email. And this is easy and simple for a demo, especially to a demo to some of the executives that I'll demo this to from Pan Tan. But any of us that have written to a REST-based API certainly knows that there's better ways of doing this. I'll get to the REST-based API next. But once again, for demoing to execs, this is certainly the way everyone wants to see things. Write an app for it, create an app for it. So we've created an Android app and we've got an iOS app in progress right now. But it's a mobile interface. It's a push-based notification interface where your mobile app, you then register to one or more Z trustee servers. We always think about this as one or more clients registering for one or more servers. In this case, all the communication happens over SSL. It's authenticated. The packets are still encrypted, also using GPG and these bouncy castle in Java and Android to handle this. Whereas we use GPG2, libgcrypt and on the programmatic on the server side. There's a bunch of screens. Only grab the one screen. That's the vote up, vote down type interface. And this is a basic deposit and this would be the place to add more information about which clients making this request. In this case, Casey could vote up or down or abstain. The middle ones is kind of hiding abstain from this vote. But I think the one that most of us here would be, at least to this crowd, I think would be interested in is the programmatic sense. I mean, I really want to program trustees that behave and make those decisions. I want to have cron jobs or demons that are authorizing or denying requests based on perhaps the time of day. It's about a five line Python script to have a trustee that checks in every 60 seconds. And besides, if it's between 1 a.m. and 2 a.m. on the first Sunday of the month, approve this request. Or if it's not between 1 a.m. and 2 a.m. on the first Sunday of the month, deny this request across the board. In this case, this is a couple of lines of shell code. The Z-Trustee command itself is just a bit of Python. It's architected like Git, where the first argument's always an action and then it's got a bunch of contextual options after that. But the Z-Trustee pending command would show a JSON data structure of all the pending requests. And in this case, so to your point or to your question, we have identified the client that's made the request. So that data is available. We just didn't expose it in the email interface yet. But we know the client fingerprint that's made the request. We know that the email address or the text associated with that client. We know when the request was created, the deposit that it's been identified, the expiration of this request, and then some justification. In this case, just for an example, we've put where justification for one of our servers might require the title of a Beatles song, for instance. And it's always kind of changing. But if I see a request that doesn't have some bit of information that reminds me of the Beatles, it's not a valid request. And that's from more of a human-to-human than a machine. But it's a form of a challenge response or a shared secret. This request has a UUID. This is the role of trustee. There's a couple of different roles, and everything we identify by these 256-bit single-use UUIDs. We base 62 and code them to make them a little more URL-safe. And then there's an authorized and a denied command. The authorized command would take that UUID and package it up into the way that encrypted sign, JSON data blob, is supposed to look for the server to respond to it. And it can mark that request as authorized or it can mark that request as denied. I had every intention of creating the same blob in Python, C, and Java. And I didn't get around to it today. But fundamentally, import Z-Trustee and then Z-Trustee.pending, blah. I mean, it's gonna look exactly like you'd expect in Python, C, or Java. Yeah, so when a client makes a request, the default, if unspecified, the timeout is 12 hours. But you can specify any timeout you want. You can say, make this request. I need a response in 60 seconds or else I'm gonna assume it's wrong. It's specified if the timeout's too long or too short. Too short. Yeah, perhaps. I mean, we scale pretty linearly with CPU and disk IO. It's not a very memory-intensive operation unless your deposits are huge. We have put multi-gigabyte deposits, but I mean, Dropbox is a better solution for that than RS3 than this. No, it's actually multi-preddit. So on the Apache side, on the server side, we're using Apache and Postgres by default. We actually use SQL Alchemy so that SQL backend can be replaced. We test it with SQL Lite, MySQL, and Postgres. We've gotten the best scalability out of Postgres. It's an Apache web server. We've looked at IngenX, but so far, Apache's done pretty well. Out of the box, it's about 100 connections, simultaneous connections it can handle. Using, there's three tweaks to make to scale that up. You increase the number of threads in Apache. It's a Python WSGI module. You increase the number of threads in Apache. You increase the number of connections in Postgres. And you need to increase, there's a syskittle that needs to be updated. I forgot which it is, but we've documented it in the server man page. It's a, and with that, we've taken it up to, I think 10,000 simultaneous connections in the largest instance we could find in Amazon. We're working on our clustered, sharded, high-availability type solution where you could put these in multiple systems. We've got a design that works on paper and we're in the process of implementing that. That'll be, that's targeted at this summer, June, July. Excuse me, please. Yeah, great question. I get to that toward the very end. So I'll short-circuit straight to that and circle back. It's offered as a SAS model, multi-tenant SAS. It's offered as a private, dedicated SAS. And it's offered as an on-prem. And so far, the adoption has been mostly on the on-prem solution, which is the, it's not unexpected, but I mean, that's where people are deploying this and doing it internally. Absolutely, totally. Yeah, absolutely. Security is a funny field. It's real hard to get, and it's one of the real challenges, especially in a startup world. It's really difficult to have advocates who publicly will come up on stage and say, we use this theory, but it's just inviting trouble. Yeah, no, personally, I mean, I'm the CTO and architect of this software. I would much rather, not much rather, but I certainly like it when someone takes this and deploys it behind their own firewall, maintaining other people's appraises. It's something we do, but it's touching. Yeah, so the first thing to understand that's extremely important for this is that every single deposit that's put onto the Z-Trusty server is encrypted using the public key of the client that put it there, okay? So even though the root administrator of the Z-Trusty server can't read the data, that's in the content column of the deposit table, the database. They could tamper with it, they could destroy it, they could, our root user could authorize releases. There's bad things it could do, but the data itself to compromise that data would involve compromising both the client and the server, obtaining the private key on the client and the server. Of course, you can put a passphrase on the GPGP on the Z-Trusty client, but that really hurts your, that really makes it difficult to do any sort of machine to machine communication. Now you also require a passphrase as well. There is one exception to what I said about everything's encrypted. There is at customer request, there is an optional feature, any deposit can be defined as recoverable. So there's sort of an escrow mode for Z-Trusty where instead of asymmetrically encrypting it using the client's public private key pair, instead a shared secret is used, a shared symmetric key is used so that an administrator of the server could recover data. That's not the default, it requires an override on every single client that wants to put that data. It's not, you know, it's, we've tried to, anywhere we could have taken a secure approach, we've taken a secure approach and offered the less secure approach as an option. Okay, sure. Yeah, let me see what do we have left. We have about 15 minutes and I have a couple of slides and then we'll open it up completely. So the voting policies, here's a quick example what this looks like. Generated password, this password never landed on disk, it went straight from memory from PWGIN directly into Z-Trusty. It's a Z-Trusty put command with a dash C says the contents are dash, standard input and I've defined three trustees. One is on call at example.com. Another one is sales at gizang.com. This is who you'll contact if you want to know more about Z-Trusty. And the third is actually identified by a fingerprint. We identify clients, trustees, processes, anyone can be identified, that has a fingerprint on file can be identified by their full fingerprint. We only use, we always use this canonical form which is the bit length or the key length, the algorithm and then the full 40 bit key is actually some attack service now for key collisions in GPG especially if you just use the short key. We always use the full fingerprint, the key length and the algorithm. A subsequent get of that deposit, this one's identified by the TUIB, instantly puts this shell command into a waiting poll until and it will check back at the server on a slow back off for up to 12 hours by default. You can always override that timeout but it'll put this into a poll and the server will not release that deposit until those two votes are acquired. So there were three trustees, two of the three have to approve the release of this deposit. If any one denies the release before two have voted in favor of it, one denial is considered authoritative. It has to happen before the sufficient number is reached. And so in this case this will sit until those two are retrieved and I guess I forgot to copy and paste the actual retrieval but assuming that the two email addresses are the client authorizes the release, that deposit will come because it came, went in on standard in, it's gonna come back out on standard out. You can actually use files or directories as well with C-Trustee. So instead of standard in, you can give it a file path which on a successful retrieval will unzip that into dev-shm shared memory. You don't wanna write it to this or you can specify a dash F and tell us where to put the file. In another case, we've actually got a, this is sort of a consumer of Z-Trustee. We've written a C program called Z-Off which uses the C library for Z-Trustee. So, you know, pound includes Z-Trustee.h. And what this at Z-Off does is it actually adds the whole PAM authentication that I mentioned before in reference to Randall X KCD. So you don't make me a sandwich. Well, give me your authorization code. And that's how Z-Off works. So you can actually add one or more trustees into Z-Off and then you can add off sufficient or off that should have been required, excuse me, off required PAM Z-Trustee into anything in PAM. In this case, this is Pseudo. And so Pseudo apt-get install, you know, some program and then with depending on where you put it in the PAM stack, you're put it after common off, then it would await Z-Trustee authentication. And that would be for anything that went through the Pseudo stack. Imagine the same thing for a screensaver for login or console or SSH. It might be, but it could be programmatic, you know? That might not be a human that you're waiting on. It might just be a program making sure that you're inside of a maintenance window. You could block access to SSHN except for inside of a maintenance window and do that, you know, programmatically with a separate system. So is this something completely different? The title of the talk was multi-factor authentication. The more I started working on this particular expression of the idea, I've been talking about this idea for over a year now, but it's actually more like multi-factor authorization. And I did a little searching and I really didn't find anything called multi-factor authorization. So that's why I'm trying to use multi-factor off and shorten it and leave it as a mystery which one we mean. But the key is that, you know, any information object can be dynamically requested and retrieved from Z-Trustee. There are ways to protect data that has to stay local in the system. That's encryption. You know, we've got a whole other product speed based on encryption. I co-author and I maintain eCrypt.fs, a cryptographic file system for Linux. There's DMCrypt. There are ways of protecting the data locally that has to be written to the local storage. But when you actually want to protect the data and you want to protect it by, instead of storing it local, storing it remotely in a trusted service, a trusted server and retrieve it dynamically, use it and then discard it. You know, only store it in M-locked secure memory or something like that. This is a way of doing that. So, you know, getting to your question about is it available as SaaS or on-prem? It's actually available as both. There is a SaaS service, but for anything other than a couple of deposits, we recommend either dedicated in the cloud or, you know, ideally on-prem. The server itself installs easily on Ubuntu 12.04 and newer REL, CentOS 6, Slash 11. It's, we package everything as devs in RPM, so it's an appget install or a yum install away. The servers have, you know, sort of a limited footprint in terms of what's required there. But the clients are available on pretty much anything, the Python, the C, the Java, it's all extremely portable and anything that has a modern Python stack or a modern JVM can run this. And I even say hesitantly that Mac, Windows, and Android especially, we've tested very thoroughly, but we've even done puts and gets on Macs and Windows using the Java client. So the client we look for, you know, sort of ubiquitous support. The server is kind of on a customer by customer basis. We did it on Ubuntu first and then we got a customer of RAS for REL and we got a customer of RAS for Slash and that, you know, that kind of grew like that. It's across both Amazon and Rackspace. We've got Failover. It's public cloud, yeah, it's public cloud. So that's me, you can find me any of these places and I think we have right at 10 minutes left for questions. Yeah, absolutely. I've already sent them to the presenter. I'll put it on my blog and leave it out a bit later. Matt? So the software is commercial software. So there's an alt-right reserved at the top. It's in Python. It's perfectly visible. We haven't obfuscated it. It's copyrighted and that's our, it's not, I mean, that's a commercial discussion. I know for this crowd, I would love to say that our clients are open source and the server's proprietary or it's all open source and we may get there one day for a small startup and this is where we're at. But it's not obfuscated in any way, shape or form. We send patches and I'd be more than happy to accept them but yeah, it's the Z-Trusty part of this is commercial. There's quite a bit else in the presentation that is freely available. Some of the offy stuff is kind of cool. Offy doesn't work at the ham layer. It works only as an SSH config option but that's another simple way of doing it. Most of the other services are commercial as well, Google Authenticator and AWS so. Great question. We do, we work with SafeNet and Tollis. There's a couple of ways we actually can set and this is kind of the default answer inside of the company whenever someone asks, can you do this? Make a trustee out of it. What we've actually done is set, use the HSM Java API and created a trustee out of an HSM. So you request a deposit which is cashed and in this example, this customer is running in Amazon or something. Amazon now has cloud HSM but before that happened, this is essentially a software version of an HSM. Something store data there and you fetch data from and someone said, well, can you integrate? I want the HSM to decide whether or not I get this data. Oh, okay. Oh, well, so the only thing that we've so far integrated with the HSM are the root of trust fundamentally because at the heart of the Z-Trustee server is a GPG private key, an SSL certificate. The same things we're telling you put into Z-Trustee, well, it's got its own. Put it into another Z-Trustee and cross them together or put it into an HSM. So we've got another use case where customers storing encrypted data in a public cloud. They run a Z-Trustee server in that public cloud but store the private keys for the Z-Trustee server in an HSM in Europe. And so they sort of have this root of trust that ultimately requires at some point if they power down some piece of the puzzle, it ultimately requires a connection back to their VPC or their VPN to their data center in Finland or something. What that gives them the ability to do is pull up log but not every single request and there may be thousands of them per minute has to go through that VPN to an HSM which is we can kind of sort of cache that typical hierarchical cache. No, go for it. Yeah, so we designed this originally for our encrypted file system. So I've maintained, we do quite a bit in the open source, I've maintained eCrypt FS for about five years. It's a stack file system in the Linux kernel it's used by Ubuntu and Chrome OS and there is other, yeah, it's really interesting and it actually forms the heart of, well we actually support DMCrypt and eCrypt FS but those two form the heart of our encrypted file system solution. The thing that's never been available in pure open source has been the key management aspect. And so Gazang was originally funded and founded based on the concept of there's more encryption that needs to be done in first relational databases and now no SQL and cloud file systems. The missing piece for actually getting all that to work is encrypting is easy. Where do you put the keys and be able to reboot your system? And so what we have are a set of net scripts and upstart jobs that at boot time will go out and fetch the keys necessary to mount your file system and you can put a trustee on it so that at two in the morning when your web server reboots this your system administrator might get a message on their ZTrustee mobile app that says you wanna approve this request and it might be up to him or her to make a couple of phone calls and make sure that this is expected and if so approved and no one has to log in anywhere. Oh and by the way, that's this admin didn't actually have the private certificate or the private password. All they did was authorize the release of that to a system that maybe your separation of duties are such that they don't have root on that box. They have the right and the responsibility to release the private cert to that machine that's required to mount the file system but they don't actually have access to that system. So we originally built this to solve our own problem of when you store keys that you need to have at boot time. Our first few customers grok the concept and said yeah, but I wanna store my other keys in that. Yeah, but my HSMs are really expensive. Yeah, but I can't get an HSM into the public cloud. And that's where we started expanding this concept and built something that was more general purpose. It works well and we're sort of our first own customer for this. Any of our encryption customers are also customers of Z trustee, but it's also general purpose. Yes, no, I must have been, I probably didn't make that transition smoothly. It's a different approach to the same problem. I probably didn't make that transition seamlessly enough. I didn't wanna spend this entire hour talking about Z trustee all by itself. This is multi-factor authentication in the cloud. So the TOTP based stuff works really well, especially for the services where humans are involved. So that's kind of this slide is the TOTP stuff it's easy when you can have one of these things in your pocket, but a bit more difficult when you're talking about a machine to machine. And in fact, I haven't done a full dissection of the Z trustee protocol, but in fact, inside of every single Z trustee message, in addition to being signed and encrypted, there's also a sequence number. It's not even a sequence number. It's a randomly generated code that the server and the client exchange so that if that client is duplicated somewhere else, then the somewhere else hijacks that connection and now it's considered that client. It's trying to prevent multiple Z trustee clients from authenticating and you need to know the shared secret, but yeah, or be able to calculate. Yeah, really, okay. I've used AFI and I've used Google Authenticator from time to time. I try Google Authenticator on all of my Google accounts all the time and man, that's a lot of Google Authenticator and get me your code. If you're a Google docs user, you have multiple devices, you can tune it down to only on logins, which is where I'm at now. So when a new device or new device logs into a Google service, you've got to type it in and hopefully your phone's nearby and not out of battery, enabling it from a programmatic sense and extending the concept from just authentication to authorization. Am I allowed to write? Is this process allowed to retrieve this bit of information? And does everyone or everything agree that it can be? The idea is that other sources, other trustees would be privy to information that is not readily available, outside conditions. Are we under terrorist attack? If so, stop releasing fees, releasing certificates. And maybe not terrorist attack, but am I under a DDOS right now? If so, let's halt the release of these. Have I decommissioned this system? So Gemolto has a lot of products and they're definitely in the physical product space, especially from the smart cards. They make a bunch of smart cards. They've got a couple of the original inventors of smart chip technology. So I'm not sure which one you're talking about. But this rotating token one is essentially the same thing as the RSA secure ID. On the IM side of things, that's certainly an interesting extension to AWS where you can give users roles who are allowed to do and not do certain things that's baked deep into AWS. And if you're in AWS security conscious, that the user, it's a great thing to use. But AWS is relegated to explicitly public clouding, not if you need to do things internally. They Amazon, AWS. Yeah, so if you take a look at the AWS multi-factor off, it's interesting, it's useful. Yeah, inside of Amazon or Rackspace, OpenStack, private cloud, public cloud, physical servers, software. Virtual machines. We do, I mean, most of our, I'd say, there's a vast number of customers using this in Amazon, but there's plenty of opportunity out there elsewhere. And so we try to take a bit more agnostic approach. We tend to run an enterprise. Yeah, if it's Linux, yeah, we're happy to encrypt it. We don't do a lot in Windows. TrueCrypt and BitLocker have that market pretty well under control. But if it's Linux, we can certainly encrypt it. The vast majority, 98% of our customers are running in server environments. But there's a few desktops out there. And if it's, I mean, I co-authored the Ubuntu encrypted home directory feature. So the checkbox encrypt my home directory. That's something that is near and dear to my heart. It's not something that Kazang does. Now, there's a bit of work that goes behind that. And most of it's in the PAM stack, actually. And PAM eCrypt FS captures your password that you enter. It decrypts, symmetrically decrypts, a long random passphrase that was generated at setup time. That's used to mount, or that's loaded into the Linux kernels key ring. Actually, the PBKDF to it. So we hash it 65,000 times, loaded into the kernel key ring. If you have file name encryption enabled, we hash it one more time. And then that key is used for the file name encryption. And then we mount home.ecrypt FS slash username on top of your home directory. And the timing has to be done exactly right. And at the right place, and as the right user to set that up properly. So there's a set UID binary, mount.ecrypt FS private that takes care of that and gets the ordering and the locks and the race conditions down right. And there were a few bugs that I had to fix along over the years, but it's just right now. And it mounts that on top of your home directory. And then to you, the user, it is magic carries taking care of the encryption in the background. But it's ensuring that to application space, to GNOME and Unity or whatever your app, Eclipse or Terminal or Firefox or Chrome, whatever's writing files and directories, it's just writing files and directories and what it looks like to be a normal file system. What actually lands on this, each individual file is encrypted. And encrypted using its own randomly generated key such that two files with identical clear text encrypt to completely different cipher text. And yeah, that's all built into Ecrypt FS. It's per file encryption. There's also DMCrypt, which does block level encryption. It's a lot more performant, but it's a lot less flexible. You have to encrypt an entire block device. It has to be a file or a petition or a disk or a loop file. And there's only one key for that entire file system as opposed to Ecrypt FS, each individual file can be encrypted differently. Yeah, I mean, the single point of failure in any encrypted file system is the key that's used to do that mount. So in the Ubuntu encrypted home, there's a file called slash home dot Ecrypt FS slash dot user name slash dot Ecrypt FS wrapped dash passphrase. And that wrapped passphrase would be here in that case, your single point of failure. That passphrase, that encrypted file, symmetrically encrypted file coupled with your passphrase is that single point of failure. To mitigate that, you could put that file on a USB key and put a sim length to the USB key so that it has to be plugged into the system whenever you type it in. That's a form of multi-factor off. You have to know the passphrase and have the passphrase file and remove that. And that works well enough and keep it on a USB key and don't lose the key. That's easy to do when it's physical. And that's the whole point and what I said, trying to take us from really straightforward to really difficult. When it's a physical computer and it's a USB key that I plug in or don't plug in, that's quite doable. When it's the cloud, I can't plug in a USB key to the cloud but I still wanna move that key off of the system and store it somewhere secure. And that's the Z-Trustee. So I'd say the other half of that is the single point of failure is the key that's used to mount that file system, storing it somewhere else and retrieving it on use and then protecting that retrieval using the policies, the trustees or something like that. So I'll be around to talk about this more. Thank you very much for staying. Thanks.