Jump to content
Main menu
Main menu
move to sidebar
hide
Navigation
Main page
Recent changes
Random page
Help about MediaWiki
Matthews Lab
Search
Search
Appearance
Log in
Personal tools
Log in
Pages for logged out editors
learn more
Contributions
Talk
Editing
Esim
(section)
Page
Discussion
British English
Read
Edit
Edit source
View history
Tools
Tools
move to sidebar
hide
Actions
Read
Edit
Edit source
View history
General
What links here
Related changes
Special pages
Page information
Appearance
move to sidebar
hide
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
= Blockchain applications of eSIM = Before I introduce the blockchain applications its essential to understand that eSim represents a “trusted” system. Most large-scale systems require trust in some way. Even blockchains. It’s just that the blockchain advocates neglect to mention who the trusted parties are (CPU, developers, etc.) With eSIM, the trusted parties have been formally specified and they can only participate after passing rigorous security checks, with multiple independent parties playing a role in the process [esim-cert-process]. If anything goes wrong, it is much clearer which parties are to blame. '''In other words: the eSIM PKI forces people to stand behind their claims.''' '''There are no blockchain eco-systems today with even half as much accountability.''' Blockchain systems, on the whole, seem to emphasize '''a lack of accountability''' as a key benefit. But on bad days that lack of accountability can really hurt the customer [parity]. I would argue that this doesn’t scale well for most admin tasks and that a digital identity system (that doesn’t suck) can solve many such problems. The one defined by the GSMA happens to be very well thought out, with proper documentation and transparency in place. Furthermore, since '''billions of dollars worth of revenue depend on the system staying secure, it makes the industry motivated to ensure that continues to happen.''' So without further ado – blockchain-based eSim applications. <span id="application-1-sybil-proof-identity-management"></span> == Application 1: Sybil-proof identity management == Many distributed systems work best when one entity cannot control more than one identity within the system [sybil-attacks]. For example, a decentralized Reddit works best if there is only one account per person to limit upvote manipulation, and a proof-of-stake blockchain is more secure if it can limit the amount of stake that a single actor can own. The eSIM PKI is a new tool that can be used to place a cost on creating sock puppet accounts. It costs money to purchase an eSIM capable device, and it costs time to register it. What you end up doing is forming a cryptographic key pair that is bound to an economic cost and real-life identity. Depending on the operators and manufacturers involved – you might define the weight of an identity and whether to trust it. <span id="application-2-esim-based-digital-money"></span> == Application 2: eSIM-based digital money == Every eSim is now digital money. We use the quality of the (manufacturer + GSMA + operator + card) signatures to decide its value. '''I want to note that the card manufacturer must maintain an audit log for quality control purposes as defined by the GSMAs [SAS-UP] standard.''' The standard specifies safe disposal of key pairs and requires good record keeping (among other things.) I.E., don’t reuse the same device IDs in successive cards, and keep track of serial numbers used in production, along with the people responsible for overseeing production. If a manufacturer or operator were to target the program in spite of the massive audit trail, it would be proof they cannot secure or dispose of their sensitive information, possibly causing them to lose their SAS-UP and/or SAS-SM certification and having to shut down their whole production line. '''The resulting damages from this would be immense.''' Depending on the exact currency design, you could have it act more like a bank wire and use a DAO to double-check minting for strange activity. Or have it completely automated. There are many ways it could operate. <span id="application-3-proof-of-burn"></span> == Application 3: Proof-of-burn == Proof of burn is a process of destroying resources to create new ones [proof-of-burn]. A notable example is how master coins were initially produced by destroying Bitcoins which simultaneously served as a demonstration of its perceived value. An eSIM could work the same way. By exposing secrets within the card it can no longer be used as part of a reliable mobile service. Furthermore, since only one person can use the same identity on the mobile network at the same time, the eSIM would lose most of its value even if people were willing to risk using it. Interesting note: tamper-proof, secure cards like eSIMs often include hardware measures that brick the device after N unsuccessful attempts. Cryptographic proof-of-failure may be possible. In which case, proof-of-burn has never been so literal! <span id="application-4-proof-of-stake"></span> == Application 4: Proof-of-stake == Create a new blockchain using eSIM-based proof-of-stake. The blockchain allocates stake based on the validity of the eSIM as determined by the GSMA, manufacturer, and / or operator signatures. <span id="application-5-fairer-ico-distribution"></span> == Application 5: Fairer ICO distribution == A scheme whereby the right to buy coins in an ICO is determined by the type of identities in the eSIM PKI. By choosing a number of operators that do know-your-customer (KYC) processes, it will be harder to create sock puppet identities. A fixed limit of coins per customer. <span id="application-6-mining"></span> == Application 6: Mining == If it turns out that extracting secrets from eSIM is hard to do then eSIM-based mining becomes a possibility. Depending on the eSIMs security measures, you would have to use specialized tools to extract the secret details. Again, this can all be cryptographically proven for rewards. I should note here that certification of the manufacturer dictates that they dispose of sensitive provisioning data after the “personalization” phase (where unique customer-specific information is written to a card [sas-up.]) So this is still a risk since you’re solely trusting the operator. Another idea would be to do repeated signing on the eSIM certificate details to find a proof-of-work and a valid signature. The algorithm could periodically switch which signed operator + manufacturer combination constituted a valid PoW. That way a single security issue would make a full compromise much harder. Maybe hybrid PoW / PoS? <span id="application-7-pre-paid-credit-that-can-never-expire-long-read"></span> == Application 7: Pre-paid credit that can never expire (long read) == http://roberts.pm/p2p_mobile_carriers <span id="application-8-spam-mitigation"></span> == Application 8: Spam mitigation == Require a valid eSIM identity for incoming emails. <span id="application-9-improved-registration-flow"></span> == Application 9: Improved registration flow == Automatically allow access to services on websites based on possessing a valid eSIM identity. No more time wasting registrations. Bonus points if you need to do KYC and piggyback off an operators KYC process. <span id="application-10-two-factor-auth"></span> == Application 10: Two-factor auth == Many services use SMS messages as part of a two-factor authentication flow not realizing that hackers can impersonate account owners to get replacement SIMs [sim-cloning]. They then insert these SIMs and intercept messages. An eSIM would help stop this problem as each eSIM contains unique certificates that can be verified off the card. <span id="application-11-more-secure-crypto-wallets"></span> == Application 11: More secure crypto wallets == Numerous hacks and scams in the blockchain world have occurred as a result of bad key management [crypto-losses]. Part of the problem is that people like to run wallets on regular computers which they use to access the Internet and various dangerous websites. An eSIM would significantly improve wallet security as it could be used to store private keys and place limits on signing transactions. For example, it could enforce daily spending limits, place time-delays on approving transactions [bitcoin-vaults], or require additional approval for large transactions. <span id="application-12-secure-messaging"></span> == Application 12: Secure messaging == Encrypted messaging tools have historically been too complicated for everyday people to use and asking them to take the time to generate their own key pairs and figure out how to use encryption is not happening. The eSIM chip makes this slightly easier as it already contains a valid key pair that can be used for encryption [esim-hw-sec-spec] (ECDSA.) <span id="application-13-secure-dht-node-ids"></span> == Application 13: Secure DHT node IDs == Distributed hash tables (DHTs) are systems that attempt to allow a network of computers to manage a collection of key-value pairs. For example, animal1 = cat might be stored on two nodes in a network and replicated to more nodes as the network grows or as nodes hosting it leave. DHTs can be used for all kinds of neat things like distributed file sharing and even video streaming, but they do contain one problem: '''they depend critically on good identity management to ensure that identities in the network are sufficiently random and that one entity cannot control more than one identity [dht-security].''' The problem is more complicated than it sounds if you don’t want to create a centralized registry! A simple solution is to use eSIM-based identities. Have one valid identity per node in the network. You would have a very secure, federated identity system that could be further improved with SPV-block headers (to show deposit bonds for identity registration) or perhaps proof-of-work. There are other ways to mitigate the damage that malicious node IDs can do in a DHT, but it’s beyond the scope of this post to go into them. <span id="summary"></span>
Summary:
Please note that all contributions to Matthews Lab may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see
Matthews Lab:Copyrights
for details).
Do not submit copyrighted work without permission!
Cancel
Editing help
(opens in new window)