CRYPTO AND PRIVACY VILLAGE - CATs [CryptoAuthTokens]: A Tale of Scalable Authentication

Video thumbnail (Frame 0) Video thumbnail (Frame 882) Video thumbnail (Frame 1476) Video thumbnail (Frame 2652) Video thumbnail (Frame 3528) Video thumbnail (Frame 5504) Video thumbnail (Frame 8060) Video thumbnail (Frame 9344) Video thumbnail (Frame 12558) Video thumbnail (Frame 13337) Video thumbnail (Frame 14662) Video thumbnail (Frame 15905) Video thumbnail (Frame 16737) Video thumbnail (Frame 17254) Video thumbnail (Frame 18806) Video thumbnail (Frame 19959) Video thumbnail (Frame 21406) Video thumbnail (Frame 21868) Video thumbnail (Frame 23287) Video thumbnail (Frame 24368) Video thumbnail (Frame 26715) Video thumbnail (Frame 27728) Video thumbnail (Frame 30767)
Video in TIB AV-Portal: CRYPTO AND PRIVACY VILLAGE - CATs [CryptoAuthTokens]: A Tale of Scalable Authentication

Formal Metadata

CRYPTO AND PRIVACY VILLAGE - CATs [CryptoAuthTokens]: A Tale of Scalable Authentication
Title of Series
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Release Date

Content Metadata

Subject Area
Authentication Facebook Building Software engineering Token ring Computer-assisted translation Cryptography Information security Communications protocol Scalability
Authentication Revision control Different (Kate Ryan album) Personal digital assistant Token ring Authentication Token ring Video game E-learning Endliche Modelltheorie Computer-assisted translation Computer-assisted translation
Authentication Service (economics) Different (Kate Ryan album) Token ring Bit Endliche Modelltheorie Bounded variation Communications protocol Information security
Authentication Point (geometry) Server (computing) Service (economics) Electronic mailing list 1 (number) Bit Multilateration Instance (computer science) Front and back ends Connected space Web 2.0 Personal digital assistant Different (Kate Ryan album) Freeware Computer-assisted translation Communications protocol Sinc function
Authentication Point (geometry) Service (economics) Token ring Authentication Token ring Mereology Limit (category theory) Public-key cryptography 2 (number) Type theory Cryptography Type theory Different (Kate Ryan album) Personal digital assistant Formal verification Computer-assisted translation Freeware Communications protocol Library (computing)
Authentication Token ring Token ring Mereology Scalability Scalability 2 (number) Different (Kate Ryan album) Personal digital assistant Order (biology) Computer-assisted translation Communications protocol Library (computing)
Slide rule Server (computing) Service (economics) Token ring Virtual machine 1 (number) Public key certificate Front and back ends Number Web 2.0 Latent heat Root Different (Kate Ryan album) Energy level Endliche Modelltheorie Computer-assisted translation Proxy server Form (programming) Identity management Authentication Addition Key (cryptography) Bit Proof theory Type theory Order (biology) Normal (geometry) Communications protocol
Authentication Service (economics) Validity (statistics) Token ring Personal digital assistant Different (Kate Ryan album) Video game Computer-assisted translation Communications protocol
Web 2.0 Server (computing) Group action Service (economics) Key (cryptography) Formal verification Bit Client (computing) Computer-assisted translation Public key certificate Identity management
Authentication Proof theory Latent heat Service (economics) Key (cryptography) Information Different (Kate Ryan album) Computer-assisted translation Front and back ends Identity management
Pseudozufallszahlen Functional (mathematics) Service (economics) Key (cryptography) Root Formal verification Computer-assisted translation Resultant Front and back ends Identity management
Authentication Functional (mathematics) Service (economics) Key (cryptography) Information Multiplication sign Computer programming Front and back ends Pseudozufallszahlen Derivation (linguistics) Different (Kate Ryan album) Formal verification Symmetric-key algorithm Computer-assisted translation Identity management Computer worm
Suite (music) Functional (mathematics) Service (economics) Key (cryptography) Mehrplatzsystem Public key certificate Scalability Front and back ends Proof theory Process (computing) Formal verification Order (biology) Video game Computer-assisted translation Identity management
Multiplication Service (economics) Key (cryptography) Multiplication sign Bit Scalability Front and back ends Cache (computing) Derivation (linguistics) Query language Personal digital assistant Operator (mathematics) Formal verification Arrow of time Computer-assisted translation
Authentication Server (computing) Service (economics) Key (cryptography) Token ring Multiplication sign Line (geometry) Limit (category theory) Scalability 2 (number) Web 2.0 Computer-assisted translation Physical system Exception handling Computer worm
Authentication Derivation (linguistics) Service (economics) Token ring Different (Kate Ryan album) Order (biology) Musical ensemble Computer-assisted translation Routing
Authentication Token ring Multiplication sign Authentication Keyboard shortcut 1 (number) Cryptography Field (computer science) Latent heat Message passing Befehlsprozessor Conjugacy class Personal digital assistant Natural number Formal verification Quicksort Computer-assisted translation Communications protocol Information security Computer worm Library (computing)
please welcome our next speaker you tingly she's going to be speaking to us about cats a tale of scalable authentication take the way you ting yeah okay thanks I'm Yu ting a software engineer building security infrastructure at Facebook I'm going to talk about our crypto auth token authentication protocol my team and I built to support authentication at scale they're dubbed Kats for short because crypto auth token but it's mainly just to make puns easier okay so
an overview of what I'll be talking about I'm going to be talking briefly about token authentication just the basics and then our different authentication models that we have a pre cat world and our infrastructure the lifecycle of a cat in a small use case and then a scaled-up version and the post cat world the utopia we dream of okay so about token authentication this
is like the most brief and small example of how it works so say a user wants access to a very specific resource on a back-end but for some reason they don't either trust the back-end service or they don't want to send their full credentials over the wire again and again so what they could do is send their credentials to an authentication service which will authenticate their credential and give back a token and then the user can then use this token to authenticate to the back-end service they can either keep this token Andreea to use to re-authenticate or this token can be single-use so that's like there's a lot of different variations Katz's is mainly a single-use own token so that's what will be stable with so why do we use tokens I touched a little
bit upon this when I talked about the protocol we first probably don't want to trust the back-end service entirely to send our full credentials to them or we don't we want better security and there's a question mark because if the token gets captured depending on the token protocol the token can still be here we used so security also the tokens can be made to be short living so that it really depends on how you want your tokens so that's why we use tokens and now onto our authentication models
that we have so there are mainly two
different use cases we have this is veno means an exhaustive list but these are the most basic ones and the ones we see most so the first one would be a user making a request to a web server which then makes a request to a back-end service for some resource for the user the backend service wants to make sure that the user is really who they say they are and not just someone pretending to be them an other instance would be a back-end service as educating to another back-end service but they want authentication per request so this means we can't solely rely on TLS since TLS is per connection and not always per request so both of these cases have the case of some entity be it a user or like a service wanting to authenticate to some other entity you're probably questioning me at this point like there's other protocols that exist why are you making cats and why are you building something new well we'll talk a little bit about the other ones that exist out there and why we chose not to use them a bit later but we'll walk through what a pre cat world looks like and our infrastructure to kind of see the motivations to build cats and why cats are required so in a free cat world
this is what it looks like okay cue
laughter but okay so a free cat world we
have lots of different types of tokens and these tokens are used for authenticating different entities so say a user wanted to authenticate to a back-end service that might be a different token protocol than like a back-end service authenticating to another back-end service there was even different tokens for the same type of entity just depending on how they're trying to authenticate so that's not great we want to reduce the amount of in libraries we have to keep up so that's one thing second thing was some of these tokens weren't very well scoped and the son sought the tokens if they were captured they could be replayed to many different parts of our infrastructure there isn't really a limit to where they could be used as long as that back-end service received and used that type of authentication protocol and also most of these tokens relied on public key cryptography well this was usable in the past we're getting more and more use cases where the QPS of the service simply will not allow for public key verification on every request we needed a protocol that would be able to support millions of requests per second but that didn't exist in a pre cat world which brings us to our last point our authentication was not per request and we want to deter requests so given all of these issues we wanted to build something that would scalable satisfy our use cases and flexible to our many authentication flows so the things that is a must for this new authentication token are a we
want to narrow down the amount of token libraries which means that we want this token protocol to be usable for all different entities because that's the main motivation for having all these different libraries being we want I say 1 or B ok V we want them to be scoped down and flexible we want them scoped down so they can't be replayed to multiple parts of an infrastructure we want them to be flexible because we don't we don't want to have to maintain all these different token libraries for all the different authentication use cases and lastly and we want it to be scalable so this is a scale scalable authentication after all we need it to scale given the large amount of users and user requests we want to authenticate on the order of 98 of hundreds of millions requests per second we want to token to authenticate every single one of these requests so
now we have our requirements we can take a look at our infrastructure and why we built cats the way we did and like hats were necessary this is what our
infrastructure looks like we have many many many many many many many many user facing web servers which then which receive requests from users and then send out requests to other back-end services to do different things these back-end services could be talking to other back-end services either directly or through proxies an important thing to note here is that these back-end services have usually a super high fan in but the amount of back-end services is much much much much much much less than the amount of users we have in user costs we have so this is especially important for cats since we rely on having many more user requests and back-end services that need authentication in order to not overwhelm our infrastructure in addition to this we also have different levels of trust within our back-end infrastructure our goal is to limit the amount of trust in machines and to not give equal trust to all machines so this is why we mainly use token authentication protocols this is reason number one from the token slide this is also to prevent against an internal threat model and out of our infrastructure our web servers which is the green ones have the least amount of trust we try not to trust them with any persisted long-living credentials then there are the back-end services that we trust the most these services do things like manage our keys as well as mint credentials they meant like service credentials in the form of certificates or user credentials in the form of sessions and then we have everything in-between these are normal back-end services and proxies that we trust a little bit more than web servers but definitely not enough to allow them to create credentials or have access to persisted credentials so Kathryn able us to maintain the small root or trust and how to delegate trust to less trust in machines also within our infrastructure we have a concept of identities so these
identities mean like different entities have a type as well as like a name to denote which specific entity is and we rely on the trust that is already established for these entities meaning that each entity is only trusted if they can prove they are who they say are they are using an identity proof and this comes in the form of certificates for services or sessions or could other credentials for users so now that we
have some background on the infrastructure the requirements and what we want let's look at the life of a cat and how cats fit into our infrastructure as a brief overview this is what
catification looks like we have a user wanting to authenticate to a back-end service extremely similar to any other token protocol at first glance a user will send credentials to the authentication service which will dub the cat service from now on the cat service validates and then sends something back and then the user is able to send a cat which is a token to the back-end service and that authenticate themselves as well as the request so what makes cats different in this case is the thing that the cat service sends back to explain what that is and how it's used let's look at Bullock out of the life of the cat from the top so we
say a user wanting to authenticate to a back-end service but then there's obviously a web server sitting in between bowls you say user - back in service for simplicity so before we start authenticating any cats the backend service does need to do one thing it
needs to ask the cat service for its verification key on startup the service uses its service identity along with this its certificate to authenticate by TLS to our cat service to prove that they are the backend service they say they are in our infrastructure TLS is bi-directional so the client also authenticates to the server so after they authenticate they will receive a verification key also known as a one strived team what this key is I'll explain a little bit later once we see all the keys in action so now they have
their key we can start looking at the lifecycle of a cat so when a user makes a request we know that the specific back end service requires authentication with cats so to create a cat we need to first get the user to send a request or a cat service for the users cat creation key the user will send along its identity proof which is its credential to prove they are who they say they are and which back-end service they're trying to authenticate to so two pieces of information the cat service validates the user credential and sends back the
creation key so this is a twice drive key so this is the mysterious thing that the cat service sends back and really what makes cats different so let's take a dive into what these cats keys are so
the verification key that I spoke about earlier that the backend service gets it's actually the result of a
pseudo-random function applied to a cat root key along with the backend services identity the this creates the verification key that the backend service will get okay and then another
derivation is applied on to that key again using the same pseudo-random function but this time with the verification key and the user's identity so we get the creation key which is the twice right key and now it makes sense why it's twice derived and then the user gets this this means that every user and back-end service pair will have a unique key but the verifying backend service will have the ability to read arrive these keys and this is why it's so important that we have many many more requests than back in services verifying the cats so this is the secret sauce that makes the cats different it's the key derivations it allows us to not need pre-shared keys between every user and back-end service pairing allowing us to share keys pretty much on the fly so
back to regular scheduled programming the user gets their creation key now what no we can locally create our cat and no longer need to interact with the cat service so the user can create the cat the cat contains some information like the user's identity the back-end services identity creation time expiration payload and an H Mac over all of this information using the creation key that we just got back from the cat service so this allows for a pretty flexible cat the scope of it can either be really large or super scope down by having additional data in the payload and it's completely up to the adopters of these cats to show how scoped down they want their authentication to be so the can't get sent along with the request to the back-end service when the
backend service receives this cat the first thing they need to do is read arrive the users tag creation key because they have the cat and they have the user's identity they can apply the same suit around the function we talked about earlier on to its own verification key and the user's identity to get the creation key with the creation key or the toy strived key the backend service validates the cat and the cats job is complete so there are a few things that the cats depend on that are already built in to our infrastructure and relies on the trust given to all the entities by our most trusted services the services used certificates to authenticate by TLS and users use sessions to authenticate themselves sessions or other credentials both parties are required to give their identity proofs in order to get their keys so now we've talked about cats in a small scale let's scale it up to
multiple users making multiple requests throughout the day to the same back-end service I would put more back-end services because that's more like real life but then it just gets kind of messy so what the user first needs to do when it wants to authenticate to a back-end service is to ask the cat service for
its cat creation key so it would normally look like this so give me my cat creation key but actually you only need to make one request for the key from our cat service first and then the subsequent requests will query the cache for the key and the key expire within the cache cache lookup is much faster than the query to our back-end service the entry is encrypted with a secret key that only the users has that is maintained via their session so that's a different story and this makes for great scalability simply because each user will usually want to authenticate to the same back-end service multiple times throughout the day at the same time this is all happening the backend service will query the cat service for their verification key but they'll only need to do this once on startup and maybe every so minutes and this key allows for the backend service to locally read arrive all the users creation keys so the users
have all of the keys they can make their own cats they send it along to the back-end service each of these arrows has a cat in it the operation for derivation and verification of the Mack is much faster than public key verification has much more scalable in our case so this is just one example of how cats are uses the most complex but we have other one back-end services indicating to another so now that I've talked a little bit about how cats work and how they live in our infrastructure you're probably looking at this and wondering you ting this looks a little bit like JW TS and a little bit like macarons why not use existing things why are you building something new well let's take a look at these so a cat a
JWT a tin raccoon walking to a bar I don't have a punchline for that so if
you do you can let me know and I will present it the next time I speak okay so
JSON web tokens what the user needs to do to authenticate to a back-end service is to send their credentials to authentication service and then the authentication service will send back a JWT which they can then use to authenticate to the back-end service this looks pretty similar to the cat authentication line except for the fact where the user gets back a token instead of a key this means that if we want every request and the payloads of those requests to be authenticated the backend serve on the user will need to query for a single in from the authentication service on every request usually that would be okay if the QPS wasn't too high but we need a scalable education system that will allow for millions of requests per second and querying a service for one of these tokens every single time it's just not scalable so with Pats users receive the keys instead and is able to mint the token themselves for every request since we're able to cache the key we only really need to talk to the cat service once every hour or so like I said before a subsequent requests make they can use the same key since the key is per user per verifier so because of this limitation would decided not to use JW Gees okay what about macarons this
picture doesn't really tell you when macaroons are except that they're a token used for authentication so macarons uses a CH Mac to scope down tokens with certain caveats that a request we need to fulfill in order to for the token to be valid so cat seems similar to macaroons at first because of all the key derivations and all the H Mac layering but macarons use key derivations to create the token itself but cats use the same technique to establish a shared secret between a user and a back-end service this technique allows us to create a token that works for our infrastructure given our different routes of trust [Music] yeah we're finally at the post cat world
this is what a post cat world look like
Hugh laughter again but okay
post cat world we have a much more flexible token for authentication this means that all sorts of entities that live within our infrastructure can use the same token protocol for authentication there are some token libraries that we can deprecated and which allows us to maintain many much much less token libraries so we're constantly upgrading this to fit with more use cases to hopefully deprecated more so now we have a much better scoped token as well it's better at preventing replay attacks since a token cannot be used to authenticate to any other entity other than the one Oh is already made for it's also much more flexible for scoping dependent on what the specific use case of the token is use for all the fields inside the token such as the time of the payload allows for either a really scoped down and short-lived cat or a not scoped down and pretty long-lived cat and we finally have authentication for every request since they're super lightweight and efficient than a more efficient than other tokens we have we are now able to produce a conjugation for every request and bind the tokens to these requests it allows for better security over all our messaging infrastructure actually uses this to authenticate every message sent and that's about a few million requests per second and they're not the only ones who are using this cat and protocol they're also much faster due to their symmetric nature previously we use a public key crypto but now we use private key crypto the verification is hundreds of times faster this lowers our G CPU spent over all on the sent occasion and allows a education in more places so in conclusion cats have helped to make large-scale of authentication more efficient it has also helped make our authentication more secure and it has helped me get a pusheen next to my desk
questions alright give it up for you
ting [Applause]