1"use strict";(globalThis.webpackChunktlsnotary||=[]).push([[4528],{2414(e,t,r){r.r(t),r.d(t,{assets:()=>c,contentTitle:()=>a,default:()=>l,frontMatter:()=>o,metadata:()=>n,toc:()=>d});const n=JSON.parse('{"id":"protocol/server_identity_privacy","title":"Server Identity Privacy","description":"To maximize Prover privacy, the server identity is not revealed to the Verifier by default.","source":"@site/docs/protocol/server_identity_privacy.md","sourceDirName":"protocol","slug":"/protocol/server_identity_privacy","permalink":"/docs/protocol/server_identity_privacy","draft":false,"unlisted":false,"editUrl":"https://github.com/tlsnotary/website/edit/master/docs/protocol/server_identity_privacy.md","tags":[],"version":"current","sidebarPosition":6,"frontMatter":{"sidebar_position":6},"sidebar":"tutorialSidebar","previous":{"title":"Custom Extensions","permalink":"/docs/protocol/custom_extension"},"next":{"title":"Configuration","permalink":"/docs/protocol/configuration"}}');var s=r(4848),i=r(8453);const o={sidebar_position:6},a="Server Identity Privacy",c={},d=[{value:"Handshake hash",id:"handshake-hash",level:2},{value:"Sources of handshake randomness",id:"sources-of-handshake-randomness",level:2},{value:"Signature unforgeability",id:"signature-unforgeability",level:2}];function h(e){const t={a:"a",admonition:"admonition",blockquote:"blockquote",code:"code",h1:"h1",h2:"h2",header:"header",li:"li",p:"p",strong:"strong",ul:"ul",...(0,i.R)(),...e.components};return(0,s.jsxs)(s.Fragment,{children:[(0,s.jsx)(t.header,{children:(0,s.jsx)(t.h1,{id:"server-identity-privacy",children:"Server Identity Privacy"})}),"\n",(0,s.jsxs)(t.p,{children:["To maximize ",(0,s.jsx)(t.code,{children:"Prover"})," privacy, the server identity is not revealed to the ",(0,s.jsx)(t.code,{children:"Verifier"})," by default.\nThe TLSNotary protocol mitigates the threat of a malicious ",(0,s.jsx)(t.code,{children:"Verifier"})," attempting to infer the server identity from the messages they receive during MPC-TLS.\nThe exact low-level details are outlined below."]}),"\n",(0,s.jsx)(t.admonition,{type:"note",children:(0,s.jsxs)(t.p,{children:["This property is specific to MPC-TLS. In ",(0,s.jsx)(t.a,{href:"/docs/protocol/proxy-mode",children:"proxy mode"}),", the ",(0,s.jsx)(t.code,{children:"Prover"})," supplies the server's domain name (",(0,s.jsx)(t.code,{children:"server_name"}),") to the ",(0,s.jsx)(t.code,{children:"Verifier"})," as part of the protocol, so the server identity is not hidden."]})}),"\n",(0,s.jsx)(t.h2,{id:"handshake-hash",children:"Handshake hash"}),"\n",(0,s.jsxs)(t.p,{children:["During the MPC-TLS handshake, the ",(0,s.jsx)(t.code,{children:"Verifier"}),' learns the hash digest of all handshake messages\n(see "Verify Data" in ',(0,s.jsx)(t.a,{href:"https://tls12.xargs.org/#client-handshake-finished/annotated",children:"https://tls12.xargs.org/#client-handshake-finished/annotated"}),").\nIf the hashed message lacks sufficient randomness that is unknown to the ",(0,s.jsx)(t.code,{children:"Verifier"}),", they could collect all TLS certificates in existence and attempt a dictionary attack on the digest."]}),"\n",(0,s.jsx)(t.h2,{id:"sources-of-handshake-randomness",children:"Sources of handshake randomness"}),"\n",(0,s.jsxs)(t.p,{children:["The randomness in a handshake comes from ",(0,s.jsx)(t.code,{children:"client random"}),", ",(0,s.jsx)(t.code,{children:"server random"}),", and the ",(0,s.jsx)(t.code,{children:"signature"}),' (see "Signature" in ',(0,s.jsx)(t.a,{href:"https://tls12.xargs.org/#server-key-exchange/annotated",children:"https://tls12.xargs.org/#server-key-exchange/annotated"}),"). For optimization, both ",(0,s.jsx)(t.code,{children:"client random"})," and ",(0,s.jsx)(t.code,{children:"server random"})," are revealed to the ",(0,s.jsx)(t.code,{children:"Verifier"})," during MPC-TLS. We argue that the ",(0,s.jsx)(t.code,{children:"signature"})," contains sufficient randomness unknown to the ",(0,s.jsx)(t.code,{children:"Verifier"})," to prevent the dictionary attack described above."]}),"\n",(0,s.jsxs)(t.p,{children:["Note that the signed message ",(0,s.jsx)(t.strong,{children:"is known"})," to the ",(0,s.jsx)(t.code,{children:"Verifier"}),". This message is computed as H(",(0,s.jsx)(t.code,{children:"client_random"})," + ",(0,s.jsx)(t.code,{children:"server_random"})," + kx_params), where"]}),"\n",(0,s.jsxs)(t.ul,{children:["\n",(0,s.jsx)(t.li,{children:"H is a hash function, usually SHA256"}),"\n",(0,s.jsxs)(t.li,{children:["kx_params are ECDHE key exchange parameters known to the ",(0,s.jsx)(t.code,{children:"Verifier"})]}),"\n"]}),"\n",(0,s.jsx)(t.h2,{id:"signature-unforgeability",children:"Signature unforgeability"}),"\n",(0,s.jsxs)(t.p,{children:["Unforgeability is a key property of signature schemes that ensures that even if the attacker (the ",(0,s.jsx)(t.code,{children:"Verifier"})," in this case) knows both the message the public key of the signer, it is computationally infeasible to forge a valid signature for that message."]}),"\n",(0,s.jsxs)(t.blockquote,{children:["\n",(0,s.jsxs)(t.p,{children:["We follow the terminology from the signature forgery taxonomy here: ",(0,s.jsx)(t.a,{href:"https://crypto.stackexchange.com/questions/44188/what-do-the-signature-security-abbreviations-like-euf-cma-mean/44210#44210",children:"https://crypto.stackexchange.com/questions/44188/what-do-the-signature-security-abbreviations-like-euf-cma-mean/44210#44210"})]}),"\n",(0,s.jsxs)(t.ul,{children:["\n",(0,s.jsxs)(t.li,{children:[(0,s.jsx)(t.code,{children:"EF-CMA"}),": Existential Forgery under Chosen-Message Attack"]}),"\n",(0,s.jsxs)(t.li,{children:[(0,s.jsx)(t.code,{children:"UF-KMA"}),": Universal Forgery under Known-Message Attack"]}),"\n"]}),"\n"]}),"\n",(0,s.jsx)(t.p,{children:"All TLS signature schemes are EF-CMA-secure, but we argue that even the weaker UF-KMA security would suffice for our scenario where an attacker is given:"}),"\n",(0,s.jsxs)(t.ul,{children:["\n",(0,s.jsx)(t.li,{children:"an arbitrary message,"}),"\n",(0,s.jsx)(t.li,{children:"a public key, and"}),"\n",(0,s.jsx)(t.li,{children:"many arbitary messages and their signatures collected from previous server interactions."}),"\n"]}),"\n",(0,s.jsx)(t.p,{children:"This scenario fits precisely within the UF-KMA model. Since UF-KMA is a subset of EF-CMA, we conclude that our approach is secure."})]})}function l(e={}){const{wrapper:t}={...(0,i.R)(),...e.components};return t?(0,s.jsx)(t,{...e,children:(0,s.jsx)(h,{...e})}):h(e)}},8453(e,t,r){r.d(t,{R:()=>o,x:()=>a});var n=r(6540);const s={},i=n.createContext(s);function o(e){const t=n.useContext(i);return n.useMemo(function(){return"function"==typeof e?e(t):{...t,...e}},[t,e])}function a(e){let t;return t=e.disableParentContext?"function"==typeof e.components?e.components(s):e.components||s:o(e.components),n.createElement(i.Provider,{value:t},e.children)}}}]);
Line numbers count LF bytes from the start of the resource, as the search results do. Vendor segments are library code the classifier recognised; they are stored but not indexed. Bytes are shown as Latin1 characters, one per byte.