Metamask - Support for signature requests and minimising associated security risks by Jyoti Puri

Transcript

um hi everyone so uh this talk is about digital signatures and how they work in manamas so this is going to be a bit of technical topic and uh yeah a bit about me I'm Jyoti Puri and I'm Tech lead of metamask confirmations team I work at madamask involve transactional pages and signature request Pages basically any confirmation page that you see and use within malamask is our area of work and this talk um we'll talk about what are digital signatures how do they work and what's the math behind them and the role of digital signatures in blockchain what are the different use cases that digital

signatures enable then we'll look at the various signing methods from each sign personal sign to sign type data sign and win ethereum and what's new in upcoming eips for Signature requests now to begin with what are digital signatures now the use of signatures to verify documents date backs to 17th century there have been years like for a long time now digital age has changed the means of communication and thus the means of signing has also changed and of digital signatures are used to sign digital messages and digital signatures actually cryptographically link a

message to an identity and digital signatures are based on algorithms so um how does it work with blockchains and cryptography is they use public key cryptography so by that like if a user Bob assigning a message using his private key then nobody can [Music] um derives Bob's private key and nobody can forge a valid signature for them but anyone who has Bob's public key can verify that the message has been signed by Bob thus Bob is able to verify his authority he's able to prove his authority by using his private career and using the private key to science

signatures now a bit of math behind digital signatures and how does that work in ethereum so digital signatures are derived using algorithm and ethereum uses something called elliptic or digital signature algorithm or ecdsa to sign messages now using ecdsa or an elliptic curve Point manipulation a value can be derived which is not reversible so we can derive a value and we can verify a value so this is like a unidirectional operation the value cannot be very can be verified but any one with the signature cannot derive back the message all the private key of

the signer so a signature is represented by a couple of three values RSV and it is stored as a 65-bit long sequence of characters now the role of digital signatures and blockchain digital signatures are building block of blockchain so if you are doing something very basic as submitted submitting a transaction to blockchain you need to sign it digitally to verify your Authority for submitting that besides submitting transaction a very important use case of digital signature is signing messages so digital signatures can be used to sign any arbitrary messages uh and by sending a message a user is proving

um on the other end that they are actually who they claim to be and to be able to sign any arbitrary message enables a lot of use cases like signing transaction offline and then sending to to the chain later or pre-authorized or agreements which can be finally settled by a third party or somebody said submitting a transaction on behalf of a user that this user doesn't have to pay for pay gas fees for transaction and this can also be used to achieve cases like scaling up the transaction settlement on chain Etc now what are the different signing

methods so um if you use signature request on metamask you see there are a couple couple of different signature requests uis there are actually a few different signature request methods and there are a few different eips which we'll discuss now um so there's our eat sign personal sign type data it has a few versions version V1 V3 V4 yeah marama supports all of these no each sign is the earliest type of digital signature and it allows signing any arbitrary hash and thus this is the most dangerous kind of digital signature because um a wrong actor can make you sign just

any hash which might be a transaction or something dangerous so um and recently a lot of scammers have been reported to be using this is if you're using metamask we actually want the users before they sign an arbitrary hash and in the last release of metamas which was which went out this February Eid sign has been disabled by default for all the users so if you want to use it sign you need to go to the settings to enable it to overcome these security issues with each sign personal sign was spent it's based on eip191 and how it differs from each sign that many two two ways one is

um the hash is prefixed with uh uh a text called ethereum signed message and length of the message so um nobody is able to um you nobody is able to uh Hash a transaction and make you sign a transaction if you're using personal signature additionally personal signature allows showing human readable text so if you're using metamask you'll see this human readable text like this it's like example personal sign message here this text is displayed to the user and as users sign but I'm also derive the hash out of it and assign it using user's private key

it turned out that personal sign was expensive and we needed it was required to have something more a more structured data to have more meaningful dap interaction and thus type sign type data was proposed which is eip712 what happened with sine type data is the proposal kept evolving while keeping the same name giving the same eib eip712 does some hard-coded versions are used for sign type data sine type data E1 V3 and V4 V2 is an intermediate for an intermediate implementation by Cipher browser now a sign type data uh allow

user to sign data which is more structured at the same time more human readable and the major design considerations behind eip712 was it should be cheap to verify on chain and should be human readable and it should be hard to fish the signature there will walk through the different sign type data version sine type data V1 it's the data looks simple json-like structure as this where where the user can specify type of the data a label for the message and the actual data with which the user is signing and madamas we display the the message like this which

is very human readable so you can read and actually sign the data but but assign type data we won had some security issues issues and those were improved further in sign type data V3 and V4 so V1 should not be used in favor of V3 and V4 sine type data B3 is is very very useful it's very secure it's very popular what it requires is that the user it requires the dab to tell a scheme which they have used for encoding the data to specify the structure of the data and also specify the domain separator so two dabs can have same data structure but for the user to be able to be sure that they are

signing the right message they should be able to know what what's the contract what's the domain which is sending this signature request so that's also enabled by with sign type data V3 assign type data V3 message looks like this where the first section in the first section the user the message specify the type of messages specified the type of domain separator actual message um and the structure of the message is specified the second part of the sign type data request is the actual message which is or Json kind of structured and a very important part of this is the domain separator so when the mass

request comes to metamask we show the structure data like this which the user can read also we show to the user the contract from where it's coming so you can actually go to either ether scan and verify that you are signing the right contract this it's it's very secure and it's the it's the most popular and recommended way signature request method now V4 is actually very similar to sign type data V3 just the underlying libraries used are different and sign tab data is using more performant libraries which are paramas is secular module and now a recent addition to Signature

request to sign in when ethereum sign in ethereum is based on erp4136 and what it allows is the user to authenticate itself to off-chain Services by signing a standard message which specifies the scope in the in the session in the security mechanism this this is an alternative for alternative of self-custodial authorization again and When comparing to a centralized Earth Systems malamas has recently added support for this not just this like for every signature request for US security is an important consideration so if you're on metamask um and we find that the sign in with

request is coming from a wrong domain we alert it to the user so reducing fund loss incidence is a very very important priority for us and at every state we want the user about it and we make sure we try to ensure that users don't do take the wrong decisions and what's next like we keep metamask updated to the latest eips and what's coming so and this week we have been discussing in the team about eip6384 which will prioritize to implement soon what what this um Erp allows is that so even though sign type data is pretty human readable but

still this aib allow more user-friendly messages so user can just read the message very easily and this message has to be provided by the contract so a contract needs to have this method of eval eip712 buffer so the wallet will call this method it will get the human readable string and display to the user and so the user can make a more informed decision about designing the request yeah so uh that was it uh about the signature request methods so we looked at what are the digital signatures and how are they computed and their significance and the use cases and the

role in blockchain and the different signing methods and sign in with ethereum now we have a bit of time for any question and answers thank you thank you [Applause]