-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathmain.tex
More file actions
83 lines (50 loc) · 16.6 KB
/
Copy pathmain.tex
File metadata and controls
83 lines (50 loc) · 16.6 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
\documentclass[letterpaper, 10 pt, conference]{ieeeconf} % Comment this line out
% if you need a4paper
%\documentclass[a4paper, 10pt, conference]{ieeeconf} % Use this line for a4
% paper
\overrideIEEEmargins
% See the \addtolength command later in the file to balance the column lengths
% on the last page of the document
\usepackage[utf8]{inputenc}
\title{Centralized Identity Authority Through Blockchain}
\author{William Shupe, Evan Hirn, Caleb Edwards \\ University of Utah \\ School of Computing}
\date{April 2020}
\begin{document}
\maketitle
\section{Introduction}
% Motivate and introduce the problem you are solving. Very briefly summarize your methodology, your experiments, and your important results.
Currently there are no wide scale, secure identity platforms where an individual can prove who they are in a timely and secure fashion. Right now, the United States uses things like social security numbers, but these numbers can be stolen easily. We would like to provide a solution where a person can prove their identity, citizenship, and potentially
other things like credit without having to worry about losing permanent identifiers like a social security number.
It takes a lot of work to reconcile the problem of losing one of these permanent identifiers. When a person in the United States loses one of these identifiers that represent their identity, it could take weeks for that central authority to fix the problem and provide new identification. This is a problem that needs to be fixed, and blockchain is the answer.
The implementation that was chosen, was being able to add new user data to the chain, edit user data, share user data, and edit private keys. This implementation was chosen because it can show without too much complexity that identity resolution through blockchain is a viable way of proving a user's identity. If a person has a name change, this will need to take place in the blockchain. This method will allow that to happen. If someone needs to share their information with a service provider, like a future employer who needs a social security number, this will be a secure way to prove their identity without the risk of just giving out any secure information. If a private key ever gets lost or is deemed insecure, it would be important to be able to change that signing key. This service would allow that to happen.
This project implementation was written in Python. There is a set of transactions that take place in testing where a user adds data, edits data, and shares data. It is important to note that when data sharing takes place, it does not have to be all of the user's data that is in the transaction. It only has to be a verifiable subset of that data. This is the data that is shared. So if a user does not want to share all data that is available on a transaction, they can choose not to do so. They can instead choose to share only a subset of that original data.
The rest of the project will cover related work, an adversary model, our methodology, the implementation and experimentation, and then a conclusion to finish. The related work will be other projects and papers that have implemented an identity authority with blockchain and how it relates to our project. The adversary model will cover how this implementation would deal with different theoretical adversaries. The methodology will explain the theoretical thinking behind this problem and why this implementation was chosen. The implementation will then be described in more detail, as well as how testing occurred. Lastly, a conclusion will take place that discusses an overview of the project along with future implementations.
\section{Related Work}
% Related work –Summarize the existing work related to your problem.
There are many different identity solutions that have been created through blockchain. What is not surprising is that there are many laws that nations follow with identity management. To make identity management feasible and producible, there are certain laws that need to be followed. One of the laws is to have user control and consent \cite{1}. This means that the user has to consent on which portion of their data can be shared publicly. This system follows this law, with only allowing the info that the user specifies to be shared with the provider asking for this information. There are different laws, like portability across different platforms that would be implemented in future scenarios for this project \cite{1}.
UPort is a decentralized blockchain that is more focused on email and banking \cite{1}. Each node has a Ethereum virtual machine installed and has to create a controller and proxy to be added as an acceptable node in the chain. The private key of this service is stored on the user's device where they have the VM installed. The way that uPort does key recovery, is that the node has picked trustees who approve new key requests when sent by the node that lost the key \cite{1}. This differs from this project implementation in that when a key needs to be changed, the user sends the private data encrypted with the new key. If the new data matches the old data, then the private key is updated.
There has been a patent submitted for payroll based blockchain identity \cite{2}. This is also something that we wanted to base this project on. There needs to be a way for companies to allow the data of the user or employee to be solely in the employee's hands without other entities getting their hands on that data. The payroll based blockchain has the centralized authority encrypt the user data with a public key that has an associated private key belonging to the owner of the data. There is also an associated level code that correlates to the privacy of that data. Depending on which level code that a third party asks for, the owner of that data can decrypt that information and send it to the third party \cite{2}. This allows for the company, or central authority, to encrypt the user's data and make sure it stays encrypted, while allowing the owner to give access securely to whomever might request it. Our project followed the format of allowing the owner of the data to allow access to a third party of a specified portion of data located in a user's transaction. The privacy and integrity of the data stays fully intact with the owner and how they choose to keep it intact.
\section{Adversary Model}
% Adversary model –Describe the adversary you are securing against.
Adversaries will be naturally drawn to identity services due to their importance in society. Currently, an adversary is able to steal an individual's identity using a Social Security Number. A large problem with Social Security Numbers is that they are unchangeable. We must thoroughly analyze our identity platform to insure that adversaries will not be able to burden others for extended periods of time like they currently are able to. To ensure this, we use public and private keys for encryption. Users will be able to request for new keys if their private keys are leaked. It is important to keep information out of the hands of adversaries. The blockchain data will be stored by the central authority. In case of a server break-in, the data of the users will be encrypted.
There is also adversaries internally within companies. If an employee wanted to change the pay of another employee, all they have to do is have the right credentials to log in to the system and commit that change. There could be data collection of who is logged in, and that perpetrator might eventually be caught, but there should be a way to not allow this to happen at all. Blockchain provides the solution. Since all transactions have the previous hash stored, the data cannot be spoofed without the central authority knowing and approving it. If the central authority is the one causing the problems, then a decentralized authority might be the solution for this case. A blockchain makes it much more difficult for hackers to change data within a system.
The good thing about blockchain is that the owner of the data stays the owner as long as their private key stays valid and protected. A transaction is always signed by that private key, so the rest of the chain will know that the transaction is valid if the signature is valid. It is up to the rest of the nodes or the centralized authority in the chain to determine if that transaction should be added as a new block in the chain. This provides authentication for every transaction in the chain as long as those keys stay protected. This is what makes using blockchain as an identity service so valuable. The information is protected against adversaries who wish to corrupt this precious data.
\section{Methodology}
% Methodology –Describe your solution and any other methods you have used to solve your problem.
It was decided to implement a central authority in blockchain. The nodes will be controlled by the central authority. The nodes have the ability to add, edit, and share information with certified service providers. Basic blockchain principles were decided for use in this process. Some certain identity data is signed with a private key that belongs to the owner of that data. This data would then be passed to the central authority. The central authority then creates a transaction and adds it to the blockchain. On the first transaction the previous hash needs to point to the beginning of the chain. As soon as more transactions are added, the previous hash of the transaction is updated to match the hash of the previous transaction. This follows the basic principles of adding a transaction to the blockchain, which is what we followed.
To edit any data, you would have to create a new transaction in the chain. The important part of blockchain principles is that transaction data cannot be changed or edited. So our methodology in editing data is creating a new transaction signed by the owner of the data. As soon as the user sends that new data in to the central authority, that new transaction, upon approval, will be the new associated identity data corresponding to that user. Our implementation follows the same principles that transactions cannot be edited, but identity data can be edited by creating a new transaction and adding it to the chain.
It is also important to allow a participant to change their private key. They might need to do so if their key has been compromised or lost. The way they could do this would be to submit their old data exactly as it was stored with their old key, signed with the new private key. If the central authority sees that the old data matches the new data, then the public and private key will be updated by that central authority to match the identity of the user. As long as the identity of the user and the signing key of that user has not been compromised, then this system should work.
Users will need to be able to share their data to different service providers. These service providers could be anything from automotive insurance companies to places of work or universities. Our identity service allows users to access service providers all of their information, or specific sections of their information. It is important that service providers only have access to current information when users grant permission. If a user decides to stop sharing their info to a service provider, the service provider will no longer receive updated information about the user.
\section{Implementations/Experimentation}
% Implementations/Experimentation –Describe your experiments and your results. Discuss your results.
For our experiments, we used our implementation we wrote in python. We tested the main functionalities that one would want in an identity platform. Using our implementation, we tested adding new users to the blockchain, updating user information in the blockchain, and sharing user data to service providers. When testing the addition of new users, we made sure that the head of the blockchain is the new user, the new user's transaction points to the previous head of the chain, and that the data the user sent was the same data that was added to the blockchain. We made sure to thoroughly test the blockchain by adding multiple users at once to ensure parallelism. Each user had a private key associated with a public key certificate that was associated with that private key. When a user wanted to add data, they would sign the new identity data for themselves with their private key and send that to the central authority. The central authority would then verify that identity by verifying the signature with that public key. The identity data can be anything that the user wants, as long is it matches what is in the signature. That is what makes this data valid. If it is then considered valid, it would be added to the chain of transactions.
Users need to be able to update their information in the blockchain. Reasons users may want to change their information include name or surname changes, residential moving, gender changes, etc. We made sure that once a user changes their information, that this data is still able to be accessed in the blockchain and the user corresponds to the new data and not the old. We also tested to make sure this new user data is the head of the chain and that the new transaction points to the previous head. It is also important to note that a user can add more information to their identity if they desire. If the user only has a name, they could then create a new transaction that includes their gender as well. To replace the old information, the central authority takes that key that was associated with that user, and updates the list that holds the latest transaction for that user to point to this new data. This way the central authority will not use old information for that user, and the blockchain can be up to date with the identity of each user in the chain.
Users also need to be able to share their information with service providers such as automotive insurance companies or places of work. We tested to make sure users are able to share only information they choose with service providers. This data is encrypted in transit to ensure privacy. Any service providers who the user does not want to continue sharing their information with will not get updated information for the user. For the data to be shared with this service provider, they have to have an associated public key that goes along with their name. This ensures that nobody else can decrypt the information that is being sent. The first thing the central authority does is get the latest transaction associated with that user. It then decrypts the data from that transaction and makes sure that the data that is wanting to be shared is a subset of that data that was just decrypted. If it is a subset, then it is valid to send to the service provider. There is then another transaction created for this share data that is added to the chain. The service provider can then decrypt the data provided to them. This has been encrypted with RSA and AES. The AES symmetric key was encrypted with RSA, and the AES key encrypted all of the data. So the AES is decrypted, which then allows the data to be decrypted. The data is then verified by the service provider by checking and making sure the signature of that data matches with the public key. If the verification comes back as true, then the data has been authenticated and no tampering has occurred.
\section{Conclusion}
% Conclusion –Summarize your work and your results. Indicated any future directions.
Our goal was to create a viable wide scale identity platform using blockchain technology. We focused on a system that is not only secure, but robust. Social security numbers and other forms of permanent identification are outdated, and are in need of replacement. Social security numbers are able to be stolen and abused for extensive periods of time. By using a robust platform where your personal identifier is a private key that is able to be replaced, one cannot be perpetually burdened by a leak.
In our current society, people are constantly changing their personal information. Whether they are moving to another place of residency, or changing their name, society's personal information isn't static. People should be able to easily change their personal information for all their service providers. With our proposed platform, a user would be able to change their information with one quick request. This information will be checked over by the central authority prior to being updated in the blockchain to prevent fraudulent information. (to be continued -evan)
\bibliographystyle{IEEEtran}
\bibliography{bibliography}
% References –List all the references you have used for this work.
\end{document}