Okay, why don't we go ahead and get started? And if people join us here in a minute, we'll just bring them up to speed. So thank you for joining. My name is David Boswell. I'm the senior director of community architecture here at Hyperledger. Before we get into Alexander's presentation, though, I did wanna share just a couple of resources around decentralized identity. If you're really interested in this topic, there are other places where you can go into the community. I'm sure we'll cover some of those in the presentation, but I did wanna point out just a couple of things. And here, let me share my screen. Just so you're aware. This hopefully is the start of a conversation. We invite you to get involved in the community. After the end of this meetup, that's not the end of the opportunity to talk to other people in the community about decentralized identity. There are a couple other places that you may want to consider checking out. And again, Alexander will cover some other ones, but didn't wanna point out a couple of things before we get started, just so you're aware. There is a regular meeting of the Identity Special Interest Group that is an open call where you can get involved. This is a really nice overview of everything going on in the space. It's an opportunity to meet other people doing things with the technology. So if you're interested in what Alexander shares today, please do consider joining the Identity Special Interest Group. And I dropped a link to that in the Zoom chat. And then if you're interested in some more of the technical details about what will be covered today, we do have a technical workshop coming up at the end of May that's gonna be talking about using the Hyperledger non-credits project to issue verifiable credentials. That's an open workshop. If you're really interested in the nuts and bolts and the technical details of some of this technology that we're gonna cover today, feel free to take a look at that workshop. So again, we hope that this is the beginning of a conversation that we will have with you on the topic of decentralized identity. So thank you for joining. And with that, let me hand it over to Alexander Sherbakov. He is the principal software engineer at DSR Corporation. Has a lot of experience with the technology, a lot of experience in Hyperledger around the different decentralized identity technology such as Hyperledger Indy, Hyperledger Aries, et cetera. So I'm excited to hear what he has to share with us today. And with that, Alexander, please take it away. Thank you. Thank you, David, for the introduction. So let me share my screen. Okay, can you see it? Yes. Okay, perfect. So thank you all for coming today. I'm going to discuss what I'm going to discuss today as a topic of decentralized identity or self-suffering identity. It's about kind of summarizing the years of development and this technology. And also one of the interesting things is how decentralized identity is related to the blockchain because it's quite interesting relationship. Before we start just a couple of words about us. I'm working at DSR Corporation. DSR, his main headquarter is in Denver, Colorado. And DSR has been serving the companies for more than 25 years since 1998. Last year, DSR joined the Hyperledger Foundation. DSR has about 11 technical departments like wireless embedded, web, mobile, computer vision, artificial intelligence and one of the important department is a blockchain and decentralized identity one. So David already introduced me. So I've been working with decentralized identity and blockchain technologies for more than seven years. And during this years, I had an opportunity to work and contribute to such important Hyperledger projects as Hyperledger India, Eris, Ersta. And my main goal today is to share my experience and hopefully describe what self-soring or decentralized identity is. What are the key technologies? What is the stack? We also are going to discuss some use cases and applications, frameworks, and as I mentioned before, what is the relationship between SSI and the blockchain technologies? Okay, so again, why we are talking about decentralized identity? I mean, DSR, we have a department devoted to decentralized identity and blockchain. And we've been working with these technologies for more than seven years. We contributed a lot in such projects as Hyperledger India, Ersta, and some other projects based on these technologies. Also, as I mentioned, we are the members of Hyperledger Foundation. And well, let's start with the basics. What is the digital identity? So we all have an identity in a real world, like we have NIC documents, we have ourselves, we have some physical stuff representing us. But nowadays, more and more processes go to internet and we are now more online than offline. Moreover, we have the whole internet of things. So it's not only about identity of persons, it's about identity of things, devices. By identity, we can understand a set of attributes related to an entity or to some agent representing this entity, which can be a person, organization, device, application. Basically, we can consider three models of digital identity. The first traditional centralized model is when we have a centralized organization which manages our identity, the data associated with us. Usually, the most common way to authenticate and authorize is to use some logins and passwords. And of course, it's usually a mess because we have to remember so many passwords, so many logins and we don't have almost no control about our representation of us within these organizations. So it's far from being perfect in terms of privacy, in terms of UX and so on. The second model is leveraging some identity providers. We can call it a federated identity. An example, when we have a provider and we have a way to sign in with the same credentials to multiple places, usually based on allows, open ID connect technologies. This is probably better from the UX point of view for the end users since we may not need to remember so many passwords, but still in terms of the privacy and control of our data, it's still not perfect, still not perfect because most of information about us, it's not controlled by us, it's stored somewhere on some services. And what is so unique about the third approach? We can call it decentralized identity or still storing identity. The core thing here that it's decentralized, it's usually peer-to-peer and there is no central entity which has a control about our data. So two persons to agents can communicate with each other and they have a full control of how the data is stored, shared, organized. And in order to still have some trust in verification, usually distributed ledgers and blockchain technologies can be used as a source of trust. And the core difference here that distributed ledgers, they are decentralized and it sounds like a nice way for putting a trust there, but still the whole communication, it's much more, much better in terms of privacy. Another picture comparing the non-SSI versus SSI worlds. In non-SSI, usually we have multiple representations of us, so basically on every service, on every website, we have different representation which is stored on this website. So it's not good from UX, from privacy points of view. In self-serving identity, we are at the center of communication, we control all the data and it's up to us how we use and share this data. And also what is important that the self-serving identity is a decentralized identity way, it's much better compliant to GDPR and other standards which are currently present in European Union, US, such as California and so on. As for how exactly it works and what are the concepts between these just magic words. There are two main definitions that should be familiar with, it's verifiable credentials and the centralized identifiers for DAG. Both of these standards have been developing for a number of years, but now they are part of that with 3CE and they are now a recommended standard. So I would say that the maturity this year has increased quite significantly. And let's start with the first concept, it's called verifiable credentials. Well, first of all, let's discuss what is credential itself. In this context, credential is a set of one or more claims about an entity made by some issuer. For example, for a person this claim can be like, let's consider passport, an ID, like a name, birth of date, date birth, address and so on. And basically we have credentials like a physical documents in the real world and you should have the same, but in internet, in online world. Then the next concept is verifiable credentials. Basically it's the same claim, it's the same credential, but with some tamper evident properties so that it can be verified that this credential is really true, it's really issued by a particular issuer and we can trust this information shared by the owner. And the second important concept here is the decentralized identifier, DAG. The centralized identifier can refer to any subject like personal organization theme. And the main difference that unlike some common identifiers, decentralized identifiers are the couple from centralized registries, identity providers and so on. Well, we'll discuss in more details what exactly it mean but in order to better understand how it will work together and what exactly is decentralized as an entity, let's look at the following picture. It shows these concepts in action. Usually what is important in decentralized identity is three actors, it's issuer, holder and verifier. The holder is a person like someone who actually owns that claims the credentials. Issuer is an organization or a person who issues these verifiable credentials and they're usually signed by some keys. And usually these keys are associated with some DID called DID1 here. So that's where we can see how verifiable credentials and DIDs work with each other. So the issuer has a DID, the DID has some metadata and keys associated with this. And these keys are used to sign some verifiable credential. And then this verifiable credential is sent to the holder and holder can store it, can process it. And usually the holder may also have another DID, DID2, this example and verifiable credential can be associated with this particular DID. And the verifier, the verifier, it's an entity who would like to know something about the holder and the holder can present the information from the verifiable credentials to this verifier. A verifier can do necessary steps and check that this information is correct. But it's important that it's not necessary that the whole credential is shared. It can be a different presentation. We'll talk a bit further. For example, some principles of selective disclosure can be used so that not all the information is shared or some predicates can be used in presentation. For example, the holder can prove that it's over 18 years old without disclosing the exact age. And in order to make this all work, in order to verify this presentation, there needs to be a place to store public keys and other metadata. And this place is called verifiable data registry. In many cases, in many cases, blockchain or distributed ledgers play the role of verifiable data registers. Part is important here that there is no link between verifier and issuer. So it's a process of presentation. The verifier doesn't need to communicate with the issuer in order to check this information about the holder. So it's kind of peer-to-peer, pairwise in these cases. Issuer talks with holder. It issues credential. Then holder talks with the verifier, presents the credential. And verifiable data registry as an independent source of trust is used for verification. Just another example, concrete example of these principles. Let's assume that the issuer is a university. The holder is a student, a future doctor. And the verifier is a hospital. Where the students like to be an employee. So the issuer can, the university can issue like a certificate, a diploma to the holder. And the holder can go to the hospital and present a valid diploma or certificate that's a real doctor and he can go there. No error between issuer and verifier, right? Because both of them just the issuer puts some public key to verifiable data registry, such as blockchain. And verifier can just read these keys from the registry or from the ledger from the blockchain. Okay, now let's discuss a couple of use cases and applications. Some popular applications, especially if you start looking at some demos or pilots for example, a very popular use case is to prove that you're over 18 years old. If you need to go to the store and buy something, it's one of the ways where predicate and selective disclosure can be useful. And for example, applying for a job, graduation, apply for a loan, you need to prove an employment, traveling. You can also show a valid ticket or proof of edit visa. There's a number of use cases which can be applied to multiple domain areas. For example, no customer use case. It's when these checks are done once and some credential is issued and then the same credential can be reused with another verifier without a need to redo these KIC checks again. Pass or less authentication it's one of the ways when you can just kind of skunk your code and use verifiable credentials, DIDs for this process. And the provenance origin of data. It can appear in multiple use cases related to IoT, manufacturing, whatever. Verifiable credentials and these principles can be applied not only to persons, not only to human but also to a thing, to a device for example and for example it can be used to prove that a particular part, particular device is verited, not counterfeit and can be trusted, can be used. One of the important places for adoption of these technologies is government based government related cases. For example, digital ID, digital passport it's one of the things there's a number of pilots in the world where these principles are being used. For example, in Canada one of the good references here where these technologies have been running in production. Business regulation certificates that's another thing where verifiable credentials can simplify the process of regulation to reduce bureaucracy. Proof of ownership. There can be a credential proving that you own this property and again it's good from the UX point of view from no customer point of view. Trial and transport. Part of use cases. Trial pass especially popular use case where the ticket can be actually verifiable credential and it's especially actual other checks which needs to be done together with this trial pass. For example, during pandemic time usually a vaccination certificate and proof of vaccination was needed. And it's using the sell certain density concept was a nice way to implement these principles and there were a number of real applications which implemented it. So you have one credential like a COVID vaccination and the second credential is a travel pass and it can easily be verified as an airport, gate and you can board. Healthcare. Yeah, again during the pandemic time vaccination it's important thing but it's not only about the vaccination medical prescriptions. It's also quite important information about the person that actually only the person should handle should control. So it makes perfect sense to use verifiable credentials for these kind of use cases. Medical records, again that's something belonging to the user to its identity and users should be in full control of these records. Delivery of medicine it can also be used.  Merchant use cases password less authentication when you go to the website and you can just scan a QR code and establish a relationship with this store. With this relationship it's possible to do secure chatting it's possible to integrate payments maybe to have some discounts proving that for example your employee of particular company and this company provides a discount for their employees. And IoT and manufacturing I already mentioned the device provenance origin delegation of access authentication and authorization of devices it's all also valid cases here. So now let's look at the SSI stack so we're going more details how this will work so we just previously discussed the concepts decentralized identifiers and verifiable credentials but let's see how these concepts work in more detail details. A very nice representation of this stack we can use a trust or IP stack with four layers on layer 4 on layer 4 we have the applications, ecosystems domain areas like healthcare, supply chains, whatever and real applications on layer 3 we actually have these credential exchange examples. It's where we have verifiable credentials it's where we have issuer holder and verifier where issuer creates issues, signs the verifiable credential holder owns and presents it to verifier and on this layer also there can be exact mechanisms and protocols how to exchange these credentials, what are the steps initiatives, what are the steps and verification, what are the formats of messages and so on. Okay, but layer 3 here these messages, these protocols these credentials they are transferred from issuer to holder and holder verify by some magic way and actually layer 2 answers the question how exactly what is this magic way of communication and as I mentioned one of the core properties of decentralized social identity that it's usually peer-to-peer and some peer-to-peer communication connection is established between the entities between the agents they consume this picture so usually between issuer and holder and holder and verifier they have to separate pair-wise connections and all the protocols all the messages they are sent on top of this connection and this is where actually the DITCOM DITCOM happens since we have two LEDs for example for issuer and for holder can be pair-wise LEDs or some other LED methods and authenticated encryption principles are used to make sure that the data through this connection is encrypted, is authorized and is properly secured and on layer 1 on layer 1 we have public utilities as I mentioned before in order to be able to do verification of signatures and proofs we need to have access to public keys shared by the issuer for example and that's where we may have these blockchains, ledgers which may contain this information like public keys the ID documents, the ID metadata and now let's look at every layer in more detail so we refabric credentials so we already discussed the main concept and this is a picture like the most famous picture from the W3C standard describing the workflow of refabric credentials we have these three entities again like issuer holder verifier issuer issues credential holder tours credentials and can present the presentation to the verifier and we have a refabric data registry as a source of trust which can maintain the schemas of the credentials and can maintain the identifiers and associated metadata like public in this W3C schema there is an error from holder that it can register identifiers that use schemas actually, especially in the indie and areas world usually a pairwise or peer identifiers are used so the holder is not necessary to write some data for example to the ledger to the blockchain but for issuers it's quite common that they use verifiable data registry just ledger or blockchain to put some TIDs and keys there so as for the refabric credential type so we have hyper ledger indie we have W3C refabric credential we have a number of various protocols and basically we can consider four types of refabric credentials, sometimes they are called credential flavors three of them are based on W3C standard this is JSON-LD with LD signatures like more or less common standard signatures JSON-LD with BBS plus signatures support zero-knowledge and GVT, JSON plus GBS which is also part of the standard and the fourth type, the fourth flavor of the refabric credentials is STL-ANUNCRATS for zero-knowledge and predicate historically STL-ANUNCRATS the first implementation was part of hyper ledger indie which is one of the main hyper ledger projects and these two standards were developed in parallel there are goals to converge them eventually but basically even now I believe for these four types they kind of established and every type has their own consent pros and depending on the use case, depending on the exact needs and requirements one of these ways can be chosen before we compare them in more details let's just discuss the concept of selective disclosure and predicates let's assume we have a credential we have some claims like ID of the holder name, address, date of birth some other metadata and we need to present something to verify what selective disclosure means that we are not forced to present and disclose all the data for example we can disclose only the nickname and that can be enough for the verify so the goal here is to disclose only the minimal required information which is needed to verify for this particular use case moreover predicates we can prove not just some data which is some value which is in the claim itself we can prove some predicates for example that the age is greater than 20 years like in this example and it's even better in terms of the privacy in terms of security and sharing really the minimally sufficient information this is the principle it's quite important, selective disclosure and predicates now let's look at this comparison table so we have these four flavors that we discussed just in LDLD proof just in LDBBS plus DUT and STL Anarchret as I mentioned before the first three are based on double S3C recommended standard STL Anarchret it's also mentioned there but basically there is now a separate Anarchret standard and by the way it mentioned there will be an upcoming webinar event devoted to this new initiative but historically it's not new as I mentioned the first implementation was done in Hyperledger in the later become part of Hyperledger ERSA so it's quite standard with major implementations and been used in many use cases so, selective disclosure and predicates are two concepts that we just discussed as you can see selective disclosure is available for BBS plus and STL Anarchret it's not available for common GUT or for just in LDLD proof in these two types you have to disclose all the information which can be a problem for some use cases but can be perfectly fine for other use cases predicates the only type of credentials that support it is STL Anarchret so for other types it's not available right now again if the use case requires a need for a predicate well, STL Anarchret is a good option if it's not needed which can be also true for some use cases other credentials may also work fine sterilization JSON LD is used for the first and second flavors and just the common JSON is used for GUT and STL Anarchret cryptosignature for JSON LD basically we can consider it like a more common digital signatures is an elliptic curve or like RSA and for BBS plus it's quite a new standard but very promising which allows to use selective disclosure and zero knowledge proofs GBS it's also quite common standard for devotee and for Hosea family of standards and for STL Anarchret it's quite unique it's based on zero knowledge proofs and its implementation now is available in Hyperledger URSA as part of Hyperledger URSA and it's leveraged by many other frameworks let's consider four more columns criteria here credential schema we discussed previously that credential is some set of attributes like name whatever but what exact set of attributes because it's pretty important in the use cases to understand what is the set of the attributes what are possible values what are restrictions it's important for interoperability it's important for the verifier to understand what to expect what data to expect it's important to the holder also to know what format of credential will be and for JSON JSON-LD we can say that JSON-LD context by itself provides some means, some set of attributes credential schema plus optionally JSON schema can be used as well in addition to this for JWC JSON based JSON schema can be used here and for CL Anarchret it's kind of the part of serialization but for CL Anarchret it's a bit different since there a dedicated a schema object needs to be created and the schema object defines a set of attributes for the claims, for the credentials usually the schema is put on the ledger, becomes public for example it can be put to hyper ledger in the ledger the next important criteria is how issuer shares the public key because as I mentioned in general any credential any claim needs to be signed can be more or less common standard cryptography or it can be more advanced, there are knowledge proof based cryptography but the main principle of need for a private and public key usually for all four types of credentials and is any asymmetric use cases there needs to be a way to share this public key and in standard JWC credentials usually it's assumed that the public key is the one associated with the DID to DID it's not just identify it also has the metadata like the document which may contain the public key which may contain the public key and in many cases usually these DID and DID docks are put on the ledger to make it public so that any verifier can resolve it can resolve it from the ledgers and do the necessary verification of features for CL and CRATS it's also a bit different there is a dedicated object which is called credential definition which contains a public key for the issuer which is used by the issuer to sign the credentials usually in addition to credential definition issuer should also have a DID and DID dock which both of these things usually put on the ledger for example in upper ledger indeed a third important criteria is we have a credential but it's pretty important to link this particular credential to this particular holder so that issuer needs to make sure that it's really issued to this holder and later on only this particular holder for whom it's issued can present it and in case of doublet we see credentials the first three flavors usually the holder creates a DID the corresponding keys can be either pairwise or it can be put on some public ledger and the holder can prove the ownership of this keys by some signature against this DID in the presentation so for example when the holder presents a claim to the verifier it needs to be two signatures the first signature from the issuer and the second signature is from the holder proving that the holder really owns the key associated with this very fabled credential and for CL Anocrates again it's a bit different the concept of the concept of linked secrets is used and this secret is just one key which is used during the issuance process and it links every particular credentials to this particular holder so only the person who knows a linked secret can create a proof, can create a presentation for the verifier and also it's important that it can create combined multiple credentials from even different issuers it can all link them all to a particular holder so that multiple credentials from different issuers can be used in the same presentation in the same proof and the last criteria it's revocation in many use cases the credential itself it should not be issued forever there should be a way to revoke it, for example a driver license is a good example that in case of some issues it can be revoked but in some credentials revocation can be achieved just by having the corresponding fields in the credential itself like a timestamp, for example after this timestamp the credential is not valid anymore but in many cases a real more advanced revocation which is initiated by the issuer of the credential needs to be present and for the first three types of credentials usually the status list standard is used for orientation for revocation it's non-anonymized basically basically it's kind of a list of indices of credentials that's revoked and the verifier can check it and make sure that credential is not revoked for CL and CRATS the anonymous approach is used it's based also on quite advanced cryptography, zero-knowledge proofs and accumulators and well it has some cons and pros for example it supports anonymous revocation as I mentioned but it's quite heavy for example it requires the holders to store quite significant amount of data on their side in order to be able to prepare these anonymized proofs of non-revocation and the next important point on this layer is exchange protocol for verifiable credentials because there is credential, there is some cryptography we know how it's kind of signed but properties are there but how exactly the issuer can give this credential to the holder how exactly the holder can give this credential presentation to verify this is very important for interoperability to define the standard so that the holder can work with multiple issuers, with multiple verifiers multiple implementations from multiple vendors so interoperability is pretty important here and hyperledger errors the first set of protocols one of the main goals of creation of hyperledger errors was actually the goal of standardization and creation of interoperable protocols which can be implemented, can be multiple implementations there is a set of areas RFCs which define these protocols and concepts and there is a number of implementations here we can distinguish errors, interoperability profile version 1 and version 2 so there is a set of tests which can prove the interoperability between various implementations and frameworks and this includes like issuers protocol presentation protocols protocols for established connections out of band protocols for mediators and so we can add a lot of them but with SWAT is important that as soon as protocols are implemented correctly and the test pass different implementations can work together in interoperable way the next family of protocols as part of destroyer identity foundation particularly did convit 2 has been developing there and there is a presentation exchange protocol and the corresponding issuers with three protocols and so on which is basically kind of advancing what is in areas is more details and the third way here is OpenID OpenID connect for refurbished credentials these principles has also been developed for quite a long time and now they are becoming more the main idea here is to let the users the business who got used to OpenID to easily smoothly integrate the centralized identity into existing use cases basically leveraging the same technologies right because there refurbished credentials can be issued as part of as part of usual OpenID or as workflows and refurbished presentations can also be shared into the same principles okay so now let's move to layer 2 of our trustworthy stack so we discussed the credentials we discussed multiple ways how credentials can be exchanged and now the channel how exactly it can be exchanged on this layer we have like agents and we have pairwise connections in Ditcom so basically on this layer we established a secure private communication channel which is built on top of DADs and Ditcom this picture shows what exactly this pairwise connection mean for example we have Alice and Bob as we hear as to peer to peer interaction and Alice and Bob create a new pair of DADs for this exact communication so for example if Alice would like to communicate with Carol it will be a different set of DADs and keys so usually it's peer to peer of course it can be extended to have like three parties participating in the same channel but in most of the cases it's usually just two and once these peers are exchanged Alice knows the DAD and the key which should be used to send messages to Bob and Bob knows the DADs and keys to be used to send the messages to Alice and they can establish a secure connection and start exchanging some messages during this channel during this channel so basically they are doing authenticated encryption so it's encrypted only by Bob only for Bob by Alice right and Bob can check it and as for what kind of messages are there it can be any messages for any protocols basically any protocols well in this case it's just game but in our use cases by protocols it can be the protocols for issuance and verification of credentials for example if Alice is a issuer and Bob is a holder then Alice can send messages for the issuance protocol like proposing a credential Bob can confirm accepting this credential then Alice can send the credentials itself and so there is some state machine basically which is defined as part of this protocol and finally layer one so we are talking about DADs quite a lot and now let's look in more details what exactly it is as I mentioned it's part of the level you see standard and basically usually DAD consists of two main parts it's DAD method and method specific stream like unique identifier this DAD method usually defines how exactly the DAD should be resolved and handled what are the set of rules what kind of verifiable data registry can be used and so what is important here that DAD it's not just identifier like UUID it's also a set of metadata we call it DAD document which can contain for example servicing points which can contain some keys for different purposes and this is the names this is the examples for example we can define the keys to be used for secure connection for key agreement key exchange we can define the keys used for authentication we can define the keys to be used for assertion we can define the service some endpoints so this is quite important the dockets set of metadata associated with the DAD which is put on some verifiable data registry and it can be used to establish pairwise connection to sign the verifiable credentials and so on just to summarize again where exactly DADs appear in our use cases for the issuer usually issuer has a DAD and corresponding D document contains a public key and the corresponding private key is used to sign the verifiable credentials indeed DDoC public key usually they are public and put on some ledger for the holder for the holder the holders DAD can be used as part of verifiable credentials so that these verifiable credentials is associated with these holders with this holders entity and the proof of ownership of this DAD can be created by signing using the corresponding private key of this DAD of some nouns so it usually is done during the presentation during the presentation holder can prove to the verifier that the holder really owns the DAD mentioned in the verifiable credentials right so credential is issued for particular holders DAD and during presentation holder can prove that he really owns this DAD this DAD can be public in some use cases so it can be put on the blockchain in some cases it's okay it's sufficient to use just a private DAD like pairwise pure key DAD so there is no need to put it on the ledger and DAD methods just a couple of examples actually the full is not the full is but it is most of DAD methods that can be found here in this specification and there are more than one hundred different methods for example DAD solve DAD indeed they they describe how the IDs can be created on top of hyper ledger in the solving networks or checked network it's also a ledger for identity use cases DIT key DIT peer in these entities usually the DIT dog this keys metadata it's kind of encoded into the DID identifier string itself so for DIT key basically there is no need to have a dedicated place to store DIT dog because once you have a DIT key you can decode it and you get the whole DIT dog you can get the whole public keys DIT peer is basically the same but DIT peer also has some strategy for updating this information like for key rotation making changes in DIT dog and corresponding metadata and basically there are DAD methods for maybe most of well-known distributed ledgers blockchain to root the corresponding DIT dogs and metadata on these ledgers and blockchains okay so SSI and blockchain again just to make it clear how these concepts are related to each other so what is the more important blockchain is basically optional in many SSI cases you can see that in this trust or IP technology stack blockchain appears only on layer 1 on public utilities it can be one of the implementations one of the ways for verifiable data registry what is usually stored on the blockchain what is usually stored on the blockchain for example in case of hyper ledger indie, hyper ledger areas issers, public keys issers, DIT, DIT dog it's usually put on the blockchain then credential schemas as we have seen in the case of sale and crash hyper ledger indie credentials there is a need for a dedicated object which can define the schema of the credential and it's usually put on the ledger and revocation registry it's also quite common to use a ledger as a source of trust for revocation for example in hyper ledger there is a number of transactions for this purpose what may be stored on the blockchain optionally holders, DIT, DIT dog public keys they can be stored on the blockchain but it's not mandatory in many cases just to per vice DIT is enough and finally what is never, never stored on the blockchain it's of course private keys link secrets and very fibrill credentials very fibrill credentials the very fibrill credential is never stored on the blockchain it's stored usually in the user's wallet like edge wallet mobile phone or maybe some cloud wallet properly encrypted but it's never stored on the blockchain since very fibrill credentials the whole concept of self-sorting identity that it should be owned by the holder only so it's stored only in the place where holder has access to it should not be public it should not be public public here is only like public keys, credential schemas some information which can safely be shared and well, the last section that we are going to look at today is frameworks the main frameworks in SSI world let's start with the SSI ledgers because as we have seen although basically the ledger, need of the ledger is optional but in most of the cases we do need a ledger as a source of trust to share in the public information and one of the most popular ledgers is Hyperledger Indie and for example the Sorya network which is based on Hyperledger Indie there is a number of other networks deployments of Hyperledger Indie not only Sorya like this service Sigaf and so on but they all use the same code from Indie the second well now ledger is checked Indie it's public permissioned ledger but checked it's public permission less ledger based on proof of stake with some crypto tokens involved it's based on Cosmos SDK and basically checked supports for example Ciel Anonkrat supports WFC credentials so all the main use cases and credential fliers are supported by this ledger then the next examples are like ledgers for example Ion Sytree protocol Bitcoin Ethereum network one of the concepts there that in many cases in SSI we don't need a full ordering of everything but it's sufficient just to have the order within the domain of particular DID user keys for example are rotated there and can be used to create quite efficient solutions which I just need to anchor to layer one blockchain like Bitcoin from time to time but don't need to have a global ordering of all the events there and as for SSI framework itself which implement all the building blocks for decentralized identity so it's not only the ledger corresponding to cryptography API wallets protocols and so on Hyperledger Indy was historically one of the first implementation it became part of Hyperledger in 2017 and later on in 2019 Hyperledger Ares appeared and last year a new grad initiative Anonkrat was also established Hyperledger Indy it's a gradated project but it's important it consists of two main parts this is the ledger and the client SDK Indy implements all three layers of the trust over IP models that we just seen the ledger the credentials the corresponding protocols the Indy SDK is written in Rust there is a number of wrappers for many popular languages including mobile the main and the only type of credentials that Indy supports it's CL Anonkrat sorry it was historically the first deployment of Indy ledger and well Indy SDK it's quite monolithic library that contains the code for communication with the ledger code for revival credentials, the wallet and so on and now a new generation of SDK SDKs have been created for example Indy VDR it's just focused on communication with the Indy ledger Ares Ascar it's a new wallet which is being adapted by many Ares framework Indy Shader Ares Anonkrat Ares it's also some implementation related only to CL Anonkrat's credential independent of the ledger independent of the protocol and so on so it's kind of the trend here to break this model and the many Hyperledger Ares projects already adapted to these new libraries then Hyperledger Ares it's as I mentioned is a graduated project as well and it was created in 2019s what is the core thing in Ares it's actually the specifications that RFCs the set of interoperable protocols concept and there is a number of implementations of these specifications in various programming languages for example ECAPI, Ares Cloud Python, Ares Framework Go Ares Framework JavaScript .NET, Ares VCX Rust Implementation also we have frameworks for creation of mobile applications mobile orders such as Ares MyFold Ares Mobile Legends React Native Ares Mobile Legends Semary and in order to make sure that the frameworks are interoperable important part of Ares is Ares Agents Test Harness many implementations are based on Hyperledger Indy under the hood and use Indy ledger as primary one now there is ongoing effort and trend to be ledger agnostic and to use the new ledger independent CL AnonKratz implementation and specification so we can see that this kind of feature from monolithic Indy to Ares and to AnonKratz it's been developed being adapted right now and I believe the community has a pretty good progress here and AnonKratz it's a ledger agnostic specification incubating Hyperledger project created last year AnonKratz Ares it's a Rust implementation with wrappers for popular efforts and there is ongoing effort to migrate areas many areas implementation to this new CL AnonKratz instead of Indy okay that's all that I have for today thank you digital identity decentralized digital identity decentralized identity okay thank you Alexander for your presentation I'm sorry Elvis are you asking something about decentralized digital identity okay please put your question in the chat so we can understand you more more clearly okay my name is Anton Verimyanian and I'm a PR specialist at DSR and now I suggest we will move to our QA session well first question about from Jimmy Dorsey what is new with AnonKratz David basically shared the link about it but maybe Alexander you can something to add yeah so as I mentioned AnonKratz historically was part of Hyperledger Indy and the corresponding cryptography is implemented in Hyperledger Ursa which is shared library graphic library Hyperledger and historically this implementation was coupled with Indyledger and Indyproject which is good on one hand since it provides a tool set of AZCAN tools for creation of decentralized identity as a site-based application so all necessary tools are there but on the other hand of course in terms of better interpreterability, better adaption it's good to support different ledgers it's good to support different methods and one of the goals for this initiative is to make it ledger agnostic there are kind of two generations of revival credentials the CL AnonKratz 1 which was regenerated as part of Hyperledger Indy RS and W3C credentials and of course it would be great to converge them eventually so that they're better interoperable with each other and can work together so this is also a goal and to make sure it's better addresses the current needs standards and converges this as for the implementation it's supposed to be more granular compared to what is in Indy so that it can be used as a independent of other parts of the ecosystem ok thank you Leksandr one more question from Benjamin this time how can an issue verify that the physician's diploma submitted online is not counterfeit in other words how can the DT issue verify if you're submitting a forged certificate for example a passport for a photo faked in Photoshop on the first submission yes yes but it's also important in these four layers this stack is kind of the governance procedure and the ways how to establish this trust so in particular for example let's assume we have an issuer right and the issuer can put it's DID to be used for issuance to a ledger and it's assumed that it needs to be a prestigious and trust to know that this particular DID belongs to this particular issuer and can be trusted there are some standards for example well-known DID which helps to associate for example a domain with a particular DID so for example there can be like GVT object assuming that this domain like example.com associated with this particular DID which can be used to issue refund okay thank you and I can see that Brett raised his hand maybe we'll have a live question right now Brett you can unmute yourself thank you this question may go toward Dave Boswell about the handbook is there a way to get the indie handbook you're talking about indie documentation yeah yeah that's what Daniela Barbosa said is a handbook let me get a couple links thanks here there's an there's a wiki for indie just like all the hyperledger projects have a wiki page with links to different relevant resources that may be what you're looking for if not just Brett Pingme and Zoom Chat I'm happy to share some other links as well okay perfect thank you thank you David and thank you Brett for your question one more question from Suresh what would be possible to access the slides after the session please yep sure we'll share the slides Jim Dorsey where are the public keys stored in the Aries mobile wallet where would I find them okay so if I think they're talking about the holder part since usually the mobile wallet is used by the holder like in this t-shirt holder verifier thing and it depends on the type of the refiable credentials but let's assume we use TL-Ironcrats indie types of credentials and they're basically here methods are used to establish that connection right so the corresponding public keys doesn't need to be stored somewhere on the blockchain they just stored in the wallet and exchange during the connection establishing process for the holder for TL-Ironcrats there is no need to store anything on the blockchain everything can be stored locally in the wallet including the private key secrets and the corresponding public keys are also just exchanged and stored there thanks, Alexander one more question right now from Suresh why is Hyperledger coming should Jimmy go ahead well I was wondering where the sorry is that two computer going so I'm just wondering since I'm running an instance of a VON network which is a chain to store the keys just wondering where can I find those keys as an issuer okay I'm talking about the issuer for the issuer the keys are stored on the ledger if we're talking about the VON network probably about TL-Ironcrats and Hyperledger indie then there is a dedicated transaction which is called credential definition createDef it contains the public key of the issuer which is used to sign the credentials okay there is another transaction in Hyperledger indie it's called NIM which can be used to store the keys associated with the DID keys associated with the DID which is needed in order to send a credential definition actually so usually the process is a following for the issuer issuer first of all creates a schema sorry first of all creates a DID and the corresponding public keys put it on the ledger on indie ledger then these keys the DID can be used to create a schema for credentials also put it on the ledger and then the keys needed to issue credentials should be generated and the public key can also be put on the ledger using the DID so you should be able to look up the public key given you have a DID and access to the ledger yes yes all formations public there is a number of well of course it depends on what kind of network you use but it's a public network usually there are some browsers like indie scan which can be used to look up the transactions and you should look for the bond network we're on the bond network so given the DID we should be able to look it up on the bond network thank you thanks for your question and I believe you have a question live questions from Amina Amina can you unmute yourself and ask your question hello and thank you for your presentation so I asked the question in the chat but I will repeat it I have a Mernstack project and I want to implement the ACAPI instance and I don't know how to run it locally on my machine so if you have an idea or recommend a tutorial to follow well I believe you can just look at the ACAPI repository it contains a number of pretty good tutorials how to do it also ACAPI it's one of the it's one of the key areas projects it's part of the basic SSI dense tutorial provided by Hyperledger so if you go through these steps I think it's called how to become SSI developer I followed this it's a course on Linux foundation I followed it but it doesn't have a step-by-step or clear information on how to run it locally on your machine so I've been running it since yesterday and I followed the official documentation on Hyperledger and Github but I actually always find problems so I don't know what to do my condition would be of course to look at the repository because I know that there are some Docker images but basically you can just run right so usually there is no need to just build everything by yourself also there is like a pipy version this is written in Python that you can also run so look at the repository and also there is a channel in discord for ACAPI you can I think you can reach the ACAPI community and ask questions there if you face any issues or yes thank you so much thank you one more question Suryash is interested why is Hyperledger coming up with separate credential type instead of leveraging W3C option actually Hyperledger didn't come up with a separate type historically still Anocrats was implemented before W3C standard was major enough so it kind of was in parallel historical process and as I mentioned part of Hyperledger in 2017 but W3C became recommended standard only in 2021 so 2022 actually so there was two separate processes coming in parallel but as for any technology usually it's not that straightforward there is a number of branches and like in any tree there can be multiple branches which can live together and it can be perfectly fine and also as I mentioned there are some constant pros in every of these approaches still Anocrats it's choice if you would like to have predicates but in some cases more simple cases maybe usage of W3C credentials is also fine and by the way many areas protocols support both types now they both support both W3C and still Anocrats okay thanks is having predicate the only advantage of Hyperledger credential type no it's not the only advantage predicate is one also revocation it's a bit more secure in terms of privacy it's anonymous then selective disclosure before BBS class signatures were created it was quite significant difference between a common JSON LD or DVT based credentials and still Anocrats now with BBS class of course yeah it's not a difference anymore but well if you need both selective disclosure and predicates and still Anocrats can be a very nice option so basically it's predicates and revocation one more question from Benjamin compared to using Polygon ID as a service basis how many advantages does our Hyperledger Indy have well I'm not the expert in Polygon ID to be honest but I'm not sure that actually Polygon ID provides all the principles of decentralized identity maybe I'm wrong but in any case the advantages for using Hyperledger areas Hyperledger Indy WC refabric credentials is that it's part of the standards interoperable standards which is really good for adaption of the solution which is really good to be able to use the solution with multiple vendors for example one party may implement the issuer another party may implement verifier third party the wallet and they can all work with each other since they support the same standards so it's pretty important about the standards next question can I use some Anocrats to support SII on an application that uses Hyperledger and Polygon yeah so one of the goals of new CEL Anocrats initiative to make it ledger agnostic and basically yes there is kind of an interface in Anocrats interface of this data registry like with the methods like write, read and so on and there can be multiple implementations of this interface Hyperledger Indy is one of the implementations checked ledger is another so basically now one prevents to create implementation based on polygon right so now with this initiative it should be quite straightforward to do it I'm not sure that there are any existing working implementations at least of part of Hyperledger maybe some wine polygon it is but yeah basically technically I believe it can be supported there is no reason why not and that's one of the goals of this data Anocrats initiative is to make ledger agnostic okay next question from YouTube can you share a scenario where only DLT is the only option in comparison to centralized ledger by centralized ledger what is meant because usually if I talk about distributed ledgers it's the centralized maybe maybe just a tip maybe the question is about advantages of kind of decentralized identity versus centralized identity right so the advantages that the user controls the data actually because for example verifiable credentials they usually belong they usually stored in the mobile wallet so the holder side they are not stored on some third party entity and every relationship between the holder and verifier it can be done directly in peer-to-peer fashion which is better in terms of privacy preserving the issuer part doesn't need to be involved like identity provider who issues the credentials it doesn't need to be involved there which is of course much better also Telos opens the way for example for password less and ways for like delegation and so on so it's better in terms of privacy in terms of security it can provide a very nice UX yeah that's the main thing okay next question what is the advantage of using a blockchain ledger to store the issuers public key over the issuer maintaining for verification as you said blockchain ledger is not necessarily necessary for SSI yes yes basically one of the advantages of using as a ledger since we are talking about decentralized identity then it's good idea to get rid of any points of centralization somewhere otherwise the whole concept can be broken and the distributed ledgers decentralized it's one of the centralized ways to establish trust right because the public key needs to be trusted so of course it can be stored in some central ledger if there is a full trust to the central entity but if there is no such trust then the centralized ledger can be a very good option for example even let's see this for example for example if the issuer will store its keys on its own company website what will happen if this issuer company organization is set down is not available anymore it will mean that all issued credentials won't be working because there will be no way to verify that the public key this website of the issuer won't be available but if you use the ledgers the decentralized ledgers it provides much better guarantee that the service will be available and in any blockchain even if a couple of nodes are down or malicious the whole service will still be functional and all the issued refiable credentials can be used even if the issuer is unavailable or not in service anymore or just get out of business so it's a very nice thing to really own the identity independent of some centralized parties Thank you, Alexander I guess that's it we don't have any more questions and if you still have some please feel free to ask them but anyway if you have some follow up questions you can reach our company on social media the links are in the chat or maybe by mail and whatever Okay Well I guess that's it for today Great Sorry go ahead Go ahead please I was just going to say thank you and thank you to Alexander as well and thank you to everyone who joined as Anton was saying if you have other questions again please feel free to reach out hopefully this is the beginning of an ongoing discussion and we're looking forward to talking with you more Thank you Thank you everyone Thank you Big thanks to all of you who joined us today Definitely thank you See you next time I don't want to line it up or maybe in person Sounds good


If you cannot see it, please go out. We cannot allow people standing in the room. I see there might be one place if you shift, but not everyone. Or three places up there. So it's time. So welcome our next speaker, Olexi, and his talk about Spectrefast and bringing Spectre-type vulnerabilities to the surface. So hello, everyone. My name is Olexi Olexenko, as you said. And today I'm going to talk about how can we detect speculative attacks with common and conventional dynamic testing techniques, such as fuzzing, for example. It doesn't work. OK. What does that work? OK, now it works. OK, so let's start with the motivation. Does work, yes. Let's start with the motivation. I noticed recently one pattern in information security talks that usually the speaker begins the presentation by trying to scare the audience off. So let me give it a shot as well. So are you ready? One, two, three, boo. So what do you say? It's not scary? You think it's actually kind of cute and cuddly? Well, let me tell you something.  This is Spectre. This is a speculative vulnerability that was detected a few years ago, or rather found a few years ago. And it allows us to, or the attackers, to bypass common memory safety techniques that have been deployed for many years. So to remind you how it works. Here we have a normal buffer of flow. We have an access to an array with an index. This index could be larger than the size of the array. We will have an overflow. We read some memory from outside of the bounds of this array. Have we normally fixed it? We add a bounds check here. So we check whether this index is within the bounds of this array. And yeah, it's supposed to fix the problem. So that's how it has been done for many years. It's applied in memory-safe languages. Well, in most of them. This is how we patch memory vulnerabilities in C and C++. And it's supposed to solve the problem, right? Right? Well, no. Because now we have Spectre. Spectre works by bypassing this vulnerability as false. Say we have the same snippet of code. We have the array of size 10. And we execute it repeatedly several times. So first time we pass the index of one. Accordingly, the bounds check succeeds. They execute the memory access. Then we execute it again. Now the index is three. Again, true. We execute the memory access. Now it's two. Same story. But suddenly the index is one gazillion. It's literally one gazillion. It's way out of the bounds of the array. It's somewhere far, far away from it. So what happens here? Well, the thing is that this comparison, it takes some time to, well, to calculate it. So for example, we might have a cache miss while doing the comparison. We might have some hardware fault. So we take some time. And modern CPUs, or rather the architects of modern CPUs try to squeeze as much performance as possible out of them. And we really don't want to stall the CPU for this long period of time. Because until this comparison is resolved, the CPU doesn't know where to go next. Whether to go into the true or to the full branch of this code. So how do they deal with this normally? Well, they implement so-called branch predictor. So here we have a situation. We have the CPU asking this module, branch predictor, what will happen to us? Well, the branch predictor looks at the history of this branch or similar branches. Sees that in our specific example, it passed once, it passed once again, it passed once again. So we had three passes. Well, the fourth time probably the same thing will happen. You will pass. So the CPU, being naive, it believes the branch predictor and it starts to execute this memory access and all the following code as well. Although it doesn't exactly execute it, or rather does not execute it as normal, but it executes its speculative. What speculative means is that it does all the computations necessary or it loads all the data necessary, but it does not commit the results. So all the temporary results during the speculative execution, they are stored in internal buffers of the CPU and they are not visible to the software. Eventually when the, yeah, so this, and eventually when the CPU detects that this prediction was wrong, it just discards the results and starts over from the correct branch. However, the problem here is that even though the speculative execution is not visible to the software, it still leaves certain traces on the micro-architectural level. What it means is that, for example, it might leave traces in the caches, it might start some execution units in the CPUs. For example, AVX unit is fired up during speculative execution or could be. And the attackers, if they know about this feature, about speculative execution, they could derive the results of speculative execution. So for example, the result of this memory access from these traces, so it's possible to do. However, you might ask the question, isn't it a CPU bug and shouldn't it be fixed in the hardware, right? Well, it's understandable. It is a valid question because effectively what we are doing we're given to the CPU a valid code which does not have a vulnerability and the problem is that the CPU itself is executing this wrong note in the way that we expected it to execute. So it's kind of supposed to be fixed on the hardware level. However, if we look at the strategy at what the CPU vendors are planning to do with these vulnerabilities. So here's, for example, a table from Intel's website. It lists as roles future models of Intel CPUs. And here as columns, we have different versions of attacks, micro-architectural attacks, not only spectra, but also meltdown for shadow and some others. In most cases, it will in fact be patched on the hardware level. So for example, meltdown, it's mainly in hardware level. Yeah, for others as well. So MCUs here stands for firmware patch. However, the story is different for spectra because here everything is supposed to be patched in software. So effectively what they are saying is that even though it's a flaw in our products, they are not going to directly deal with it on the hardware level. So it is effectively our responsibility as software developers to deal with the hardware issues. So what can we do about it? Well, the first or rather one of the first proposed solutions that was to add serialization points everywhere. So serializing, there are such instructions in X86 CPUs that do serialization. Serialization means that they effectively stop speculative execution. So for example, Intel has L-fence and the suggestion was to put L-fences after every conditional branch. So this does fix the problem. It does prevent spectra. However, there is one big issue. It's very slow on our benchmarks. The programs became somewhat around five times slower. There is another better approach, most fiscated. We could add data dependencies between the conditional branch and the memory access. So here's how it's implemented. It's somewhat better because it doesn't completely stop speculative execution but instead only delays the memory accesses so that it could be vulnerable but it's still pretty bad, it's around 50% overhead. So from this we can conclude that we need more precision. We want to patch not the whole program but only those parts of the program that are actually vulnerable to spectra. How do we do it? When we came up with this conclusion, we met in our group and we asked ourselves this question, how do we find spectra? Well, we thought, can we draw a parallel with other vulnerabilities? What are the mechanisms and the tools that are used to detect other types of vulnerabilities? And one of the trending techniques that we came up with is fuzzing. So how does fuzzing work? Just to remind you, it's a relatively simple conceptual technique. We just test the application that we have with the randomly generated inputs or pseudo randomly generated inputs. So in our case, in this specific case, we would generate a random integer, assign it as an index and then execute this code repeatedly. To actually detect that we have a buffer flow, we might want to use some memory safety techniques. For example, address sanitizer is one of those which would verify before every memory access, it would verify that the pointer is valid. So it points to a valid object and not to some random place in memory. However, the issue here is that even though this technique would detect memory safety violations, it will not detect spectra. As I said before, spectra or speculative execution in general is not visible to the software. So here, this check will always be valid and address sanitizer will not detect anything. So now, just ourselves, how do we make it visible? How do we make speculative execution visible, which is a hardware feature? How do we make any hardware feature visible to the software layer? Well, let's just simulate it. Let's actually execute the code that is ran speculative. And here's how it works. So basically, that's the idea behind spec-fuzz. We simulate speculative execution and then we fuzz. So let's say here's the concept. Let's say we have this control flow graph. We have node A entrance point. It could be, for example, an if-else statement and it goes either into node B or C. So C could be the if branch, B could be the else branch. And our simulation, what it does, it inserts an additional node A simulated, which is identical to the original A, but it has the opposite exit condition. So for example, if A enters B, A simulated would enter C and vice versa. However, speculative execution, it doesn't last infinitely. So it has some boundaries. For example, on the Intel CPUs, it lasts at most 250 instructions, so it's rather short. To simulate that, we additionally take a checkpoint before entering the simulation. So we store the state of the process and periodically we check whether we reached this boundary of 250 instructions and we exit the simulation and rollback. So how it works, we would execute the, we would take a checkpoint, execute the simulated branch, execute the simulated path, then eventually when we reach 250 instructions, we rollback, but we notice that we rollback not to the simulated node, but to the original one, and then we execute normal code. And we repeat the procedure for every conditional branch in the program, in the application that we test. And so yeah, coming back to an example, to the code, how it works in the code. Here again, our victim function, we have, as previously, we have condition, memory access, and we store the result. Here, now bear with me, we'll have an assembly because specfuzz is implemented as a backend pass in LLVM. So it's effectively compile time binary instrumentation. So we have to go into assembly. That's how this victim function compiles, too. We have comparison, jump if less than, then we do a memory access and we store the result. And this is the instrumentation. As I showed before, before starting the simulation, we take a check point. So here we call the functions specfuzz check point, which stores the state of the process. Then we insert the sequence of instructions that reverses or makes the direction of the branch opposite. So we had the original jump was here, jump if less than, we inserted jump if greater or equal, so the opposite direction. Then in the end of every basic block, the call a function that checks whether we reached this limit of 250 instructions, it actually depends on the CPU, but for Intel CPUs currently it's 250. And if we did reach, it rolls back to the checkpoint. And finally, we want to actually detect those memory violations, so we, oh yeah, we also count instructions here. And yeah, so to detect the memory violations, we just use the address sanitizer, which, yeah, so the call is send lot, which checks whether this pointer is within the bounds of the origin. So basically that's the idea. That's the concept of spec fuzz and high level implementation. Now let me show you a quick demo of what you can get out of it. So that would be a demo of fuzz in OpenSSL. Let's see what it works. Okay, perfect. Here we go. Here we have OpenSSL, which is built already with the spec fuzz. We have a driver for OpenSSL. Here's, oh, too quick. Yeah, here's the driver. So fuzz server, it's a driver shipped with OpenSSL. So it's a fuzz in driver, something that we test. That's the application that will be fuzz. Yeah, and if we run it even with a single input, that would be the output of it. Here we have a whole bunch of lines that are produced. Every line here is a single vulnerability detected or a single speculative overflow detected by spec fuzz. So you immediately can see a difference between normal testing of an application and testing for speculative vulnerabilities because here we have many more results than normally. Normally when you would test in applications, for example, for buffer overflows just with adjacent users, you would find maybe one vulnerability in an algorithm. Maybe in a day, maybe you would spend a whole week fuzzing and you won't find anything if it's a long established project. Here in a single second, you might find hundreds or even thousands of vulnerabilities in the workspace. And all of them are, so even with the single input we found a lot already. Yeah, so we have to deal with this. Now how fuzzing looks like here, let me move it away so it doesn't cover. Yeah, now we can fuzz this thing. Yeah, for fuzzing, we are using here just Hunk Fuzz. It's one of the fuzzing tools that are available. This one is from Google. We fuzz the application with the Hunk Fuzz. We do 10 runs here on a single thread. We use the same fuzzer as previously. So it's the driver, server driver from OpenSL. As a start in inputs, we use corporal of inputs from OpenSL again. And notice here that that's the difference from normal fuzzing, that we are piping this output, this long list of vulnerabilities into a script that collects them and aggregates into a JSON file. Yeah. So let's run the fuzzing. Fuzzing runs. Of course it takes some time because of this instrumentation program becomes quite a bit slower. Still usable, but slower. So it will take some time. Yeah, we can skip it. Okay. After fuzzing we got this file, analyzer.json. And this is a file of all these aggregated values. It's not very useful. Every line here, so the hex values here are addresses of the offended instructions in the binary. So it's not very useful. It's more convenient to work with code lines. So after the aggregation we also symbolize the results. So here we have another script that symbolizes them and turns the binary addresses into the code lines, into the addresses in the code. Yeah. And to show you one example of what we can achieve. So what we found in OpenSSL, now there will be one vulnerability that we found there. So it's in the crypto part of the OpenSSL. Yeah, here we go. The vulnerability is here. It's in the crypto part of OpenSSL and we have the same pattern as I showed you before. It automatically found a vulnerability, a speculative overflow. We have a memory access, we have an array access, controlled index here, and the indexes bound checked here and here. So almost exactly the same pattern as I showed you in the very beginning. It's an OpenSSL. Yeah, so that was the demo. But, no what. We found the vulnerabilities and we found many of them. If you have a list of say 100 or even 200 of vulnerabilities in your software, you probably don't want to patch it manually and go over all of them and try to fix them manually. So to deal with this issue somehow, we implemented another tool. It's more minor but still quite useful. We took a few of the tools that automatically patch programs but patch all the conditional branches in the program. So for example, as in the beginning I showed there are tools to add L fences after every conditional branch or add data dependencies after all conditional branches. We modified them to instrument not the whole program but only those parts that we either did not test or those parts where we found some vulnerabilities. So it's a white list approach. And let's see what we got there. So here there will be a plot of speedup of several applications, several libraries that we tested. We have OpenSSL here, we have a few parsers. So this one for example is JSON, YAML. We have a compression algorithm HTTP. And on the Y axis we have a speedup with regard to full instrumentation. So it's a ratio between the runtime of the application when it is, when spec files is applied. So we have only partial instrumentation, only those parts that are either not tested or where we found vulnerabilities are instrumented with respect to full instrumentation. So all conditional branches are instrumented. And here are the results. They're quite different here. In some cases we found very few vulnerabilities like in just me and JSON we found I believe only two vulnerabilities. And accordingly the improvement is huge. So everything else does not require instrumentation anymore. And in OpenSSL we found quite many so the improvement is not so much but still it's quite considerable. It's around 25% already. And mind that this tool is on a rather early stage. I believe we can do much better right now. But it's already a good start I would say. So yeah, that was it. If I give a presentation on a rather high level there is quite a lot more to it. So for example how we deal with nested mispredictions for example several branches could be mispredicted at the time how we deal with collecting results and everything else. You can see it in our paper. It's openly published. It's on archive, you can find it. And we also published this tool on GitCup so you can try it out, here's the link. But please be gentle because it's first academic code and we have recently refactored it so there might be issues. But if you find any issues just write me or open an issue on GitHub. Yep, so that was it from my side. I will ask for your questions and if you want to talk to me just either find me on the conference or write me there. Thank you. Were executed if they differed over a certain amount of time did you say, well, it was speculated? No, not really. We actually execute the speculative path. So we are forcing the program. So we have a conditional branch. We have the branch which the program should take. So given an input. So in, for example, in there was the example here. Yeah, so for example here. Say X value is 10 here or let's say the size of the array is 10 and X value is 11. So it's out of bounds and we are not supposed to enter this function or rather this branch. We are inserting such a snippet of code that forces the program to actually enter this branch, execute for some time and then it rolls back and executes the correct code. So that's how it works. Yes, you could. We just found it more convenient to implement it. I can't even see the question for that. Oh, okay. So the question was whether it's possible to implement it without source code. My answer would be, yes, you can do binary instrumentation. We just found it more convenient to do it on the LLVM level. And again, it's first prototype. So you can reimplement it as binary. Yes, could you please repeat? So it's a nice talk. Thank you. Have you thought about combining the, so you instrument the program to add the speculative branch as well, basically. But then you do fuzzing. Have you thought about doing static analysis instead of fuzzing to build a sound analysis? There are actually approaches for static analysis. Quite many. There is a respecter from GR Security. There are some tools, there is a tool from Red Hat and so on. But so far from what I saw in my experiments. So the problem with static analysis depends which kind you use. So if you have symbolic execution as static analysis, then it will be sound. But the problem is overhead. So it takes a lot of time to analyze it. And there are approaches for that too. There are tools for it, which try that. For example, Spectre, there's this one. And as of more classical static analysis which is like pattern matching, the problem there is false negatives. So these kind of tools, they normally find only those vulnerabilities that or rather those instances of Spectre that are envisioned by the developer. And Spectre might have different variations and those won't be catched. Yeah. Great, thanks. And actually it's in the paper. We have some evaluation for them too. A little bit. Sorry, I speak a little bit English. I would like to ask you, could you be so kind to share with us Libre SSL results? Because it's a fork from OpenSSL. It's security focus. And another question, what's happened if I tried to disable my multi-training in BIOS? Can barely hear it. Could it repeat? Multi-training. Yeah, if you disable multi-training, it becomes better but it's not sufficient. Yeah, so it's usually a first recommendation to disable hyperthreading because with the hyperthreading enabled, the attack is easier to launch. But with the disable, it's not impossible to launch. It's just harder. So it like rises the bar but you can still, so the thing with hyperthreading, do I still have time? Yeah. So the thing with hyperthreading that, okay, so if you want to start speculative execution, you have to first train branch predictor that it should go into the path that you want it to go. And you can do it either inside the program, as I showed in this example, but it's not always possible. So sometimes you cannot control the direction of the branch with the input that you fit to the program. With the hyperthreading enabled, you can train branch predictor from a hyperthread, from a different hyperthread because it's shared between hyperthreads. Otherwise, well, it depends, of course, on the architecture. Did you already tested Libre SSL? Sir? Did you already tested Libre SSL? No, we didn't. Could it be so kind to do it and share with us results? We can talk afterwards, but yeah, I'll be clear. I'll clearly do it.


Trust in medicine has been steadily declining. Today, it's in a state of emergency. How do we get here and what can be done to fix it? We've seen some great progress in medicine over the last 40 years from disease treatment to technological breakthroughs. How can we explain this dichotomy between innovation and trust? Is there a way to restore key relationships to reverse the trend? Rich, welcome to the show. It's great to be here, Drew. In 2018, ABIM launched the Trust Initiative. In an effort to bring industry stakeholders, researchers, and other policymakers into the same room to understand what's happening with trust in health care. What was behind this initiative? Well, as you said, Drew, trust in health care has really decreased dramatically. We think that's going to have implications for how much patients access the benefits of what modern medicine can give them. We hate to imagine a world where we have all these powerful tools and things we can offer patients and they don't come because they don't trust us. Why do you think this decline has been so pronounced in health care? I think it has to do with the way that medicine may have let relationships with patients deteriorate. We've become more distant. We've become more institutional. We've become less personal. And we've assumed somehow that our scientific facts will protect us. What does trust look like in the future when there's intermediaries between the doctor and the patient? Where it's not always just you sitting in front of me, but rather I'm delivering care using different types of technologies? Well, that's a great question. And technology and medicine have always been intimately related after all when the stethoscope came in in 1860 and people said, oh, that's a terrible thing. It keeps the doctor at a distance from the patient. Imagine two feet being a distance. Now you treat people across the world directly after a screen. That's right. So I think the key is to think about using technology as a tool that can build that. When you get into a car that you have summoned from an app, what are you trusting exactly? Are you trusting the app? Are you trusting the driver? Are you trusting the mapping program? The future in health care looks like using technology to enable and support relationships and to make people feel safe and cared for. I toured a brand new hospital opening in Dallas and they had in every exam room a giant TV screen. A patient had some code that they could put in on an iPhone and basically their family could call in and talk to them on the TV screen and their rural doctor from 200 miles away could call in and talk to them from the TV screen. You're actually saying we can use technology, we can leverage it to bring doctors and patients closer together? That's correct, we think about technology as a way to drive change, reorganizing care. That's why we got interested in trust because we think that doctors and healthcare, people who lead healthcare systems fundamentally care about it. Trust is at the core of the relationship between patients and anyone who's purporting to offer them healthcare. Rich, this has been a really interesting conversation. I think our viewers have really learned a lot as have I. Thank you. It's really a pleasure. Thanks for having me.