--- - Who we are - What we are building - Bridging URL and IRL - Current and future challenges --- ## Who we are <font size=6> - Hardware × Software - Principles~ - Privacy first - User always in control - Six years of building reader hw, wearable hw, and phone "wallets" for enterprise access control (employee badges) - Brought mobile access control to physical security industry~ - `Access for Apple Wallet` ~ launch partner - `CSA ACWG` ~ technical vice-chair (https://csa-iot.org/all-solutions/#access-control) </font> --- ## What we are building <font size=6> - Non-custodial wallet for digital identity and digital assets <!-- We want to take what we learned from enterprise access control, and everything that the cryptocurrency community has created for non-custodial storage, privacy, proof of ownership, and apply it to a broader class of digital assets (e.g. credentials, PII) --> - Wearable hardware wallet (NFC, BLE, SE) - Mobile software wallet - Complementary, a balance of convenience, robustness, security </font> --- ## Unique challenges <font size=6> - Limited power and physical space - Limited i/o - High degree of integration <!-- We are talking nfc radio frontend + antenna boost + SE --> - Fewer component options, less design flexibility - Table stakes for functionality~ - Must be multi-purpose, little appetite for single function wearable devices - Must support existing use cases, work on existing infrastructure </font> --- ## URL and IRL <big>Experience × Integration × Security</big> <font size=6> [Wallets Abound - The Daily Gwei #488](https://thedailygwei.substack.com/p/wallets-abound-the-daily-gwei-488) </font> <font size=6> - People have 80+ existing identifiers - People have existing things they do with them daily~ - payments - transport, ticketing - physical access control (office, home, car) - logical access control (otp, passwordless) - digital ids (mDL, MRTD, vaccine passport) - cryptoassets (coins, tokens, LNURL) - There exists both legacy and new terminal infrastructure </font> --- ## Challenge: features <font size=6> - SE limited in functionality - JavaCard for most SE applications <!-- - supporting existing use cases means we can't ignore this - simply using an SE with a general-purpose core isn't an option for adoption, most of what people want to do today is in proprietary / certified applets --> - "New" curves - Some (_e.g._ `secp256k1`) can be done with current hw, but questions about side channel resistance <!-- Others like ed25519 are more rare --> - New algorithms (signatures, ciphers) <!-- Same as above - chacha software implementations exist, but are they resilient to side channel attacks? verified in any way at all? --> - New protocols - _e.g._ `ISO18013-5` (mDL) finalised 2021-09 - Structured request/response and signing schemes for selective disclosure, CBOR, COSE, AES-GCM <!-- hard to do efficiently in javacard --> - Evolving much faster than traditional "secure" industries, hw vendors are chasing a rapidly moving target... </font> --- ## Challenge: certs and costs <font size=6> - SE constrained by cert requirements - certification is long and costly (EMVCo, GlobalPlatform, individual payment networks) - frozen hardware, OS, API, and applet code - Vendors unwilling to make changes - Vendors take forever to implement new things - `JCAPI 3.1` (2019) -- who has implemented it? - `JCAPI 3.0.5` (2015) -- far from universal <!-- especially as you move up the integration food chain - this stuff takes time to roll into new products --> - NXP SE050E added AES-GCM/CCM, Curve448 in 2022 (!)~ - likely take another 12mo before this is usable in a new product design by mere plebs <!-- even before supply chain shortages --> </font> --- ## Challenge: expertise <font size=6> - Often don't have all necessary expertise in-house - either a software house using off-the-shelf silicon, - or a silicon manufacturer or integrator outsourcing all software dev and security - JavaCard OS, runtime, applet dev often by 3rd parties - Lack of openness in docs and specs at integrator level often not by design, but a side-effect of too many cooks ("too hard to cut through all the contracts") </font> --- ## What should we do? <font size=6> - Fastest way to support new things - general purpose compute with SE-level guarantees is the most future-proof and the most flexible, but... - Co-exist with existing JavaCard and certified applets - Integrated solutions should be flexible, modular <!-- used to have pins hard-wired so specific subsystems, today we have gpio pins that are assignable in software --> - Isolation levels - let some parts move faster than others - let everyone write code - open source, developers, dedicated small volume - Can we help iterate faster or cheaper on hw implementations? <!-- emulators, hw or sw, soft-ip cores, prove out designs and use cases before they are locked into hardware --> </font> ---  @proxy ~ <a href="https://twitter.com/proxy"><img src="https://webstockreview.net/images/twitter-bird-white-png.png" width=32/></a> @simonratner ~ <a href="https://twitter.com/simonratner"><img src="https://webstockreview.net/images/twitter-bird-white-png.png" width=32/></a> <a href="https://github.com/simonratner"><img src="https://github.githubassets.com/favicons/favicon-dark.svg" width=32/> <a href="https://www.linkedin.com/in/simonratner"><img src="https://cdn.freebiesupply.com/logos/large/2x/linkedin-icon-logo-black-and-white.png" width=32/></a> &nbsp;&nbsp;