https://docs.google.com/presentation/d/13kiD_fq_wR2hIZ6tJBWbdTgu85a-jB-HC-fFBApNAYE/edit?usp=sharing
Whitepaper
https://github.com/KnoxCoin/KnoxCoin/blob/main/CS590_Writeup.pdf
Inspiration
Our team sought to make a more secure blockchain technology accessible to anyone––without requiring the massive investments in infrastructure, management, and trusted third parties that the rich use to make sure their cryptocurrency remains secure.
On current blockchain systems, a user’s private key is their single point of failure. However, this private key is also necessary for every transaction a user wishes to make. For users prioritizing security, we believe this paradox of a private key providing the root of function and the root of security is a fundamental design flaw. Because the user must keep their private key readily available for every transaction, an attacker may more easily steal it by socially engineering the user or hacking the user’s machine. In practice, this accounts for the majority of cryptocurrency stolen each year. We've carefully designed and implemented a basic prototype of a new system called Knox to protect against private key compromise and vastly improve any user's cryptocurrency security.
What it does
Let's say that Jane has invested her savings in Ethereum and wants to keep them protected. In today's world, Jane might use a wallet on her phone or computer to store her private key and provide an abstraction for Ethereum actions. The problem is: if that wallet app is hacked, or Jane's phone OS is hacked, or an attacker steals Jane's device, the attacker can use the private key to generate a signed transaction, broadcast it to miners, and have those miners transfer all of Jane's savings to their malicious account.
Knox redefines the private key single-point-of-failure design by allowing Jane to specify n security codes and a transaction delay time to associate with her public key. These security codes are just private keys, with their public keys appended to the delay time, signed, and broadcast to miners to place on the blockchain––where they are immutable and easily retrievable in the future. Jane can store these security codes in a hardware wallet, in a QR code, in her diary, with a parent, or wherever else she pleases. She can even lose some of these security codes as time goes by. As long as she retains 1 more valid security code than any attacker, she will remain in control of the funds in her account.
In Knox, similar to how trusted bank transactions move from pending to processed, all transactions carry a delay specified by the user in the initial, immutable security settings stored on the blockchain. When Jane wants to transfer funds to someone else, she can initiate a transfer request which is sent to miners and stored on the chain. After the delay period has passed, Jane can initiate an execute request to fully transfer funds to the receiving account. This delay is a crucial design limitation of Knox for everyday transactions, but it is also a crucial source of security. If an attacker were to compromise Jane's wallet, steal her private key, and initiate a transfer request to their malicious account, the attacker would not be able to execute the transaction until the delay period has passed. Meanwhile, our system (detailed below) notifies Jane via Twilio SMS that a transaction has been initiated from her account and allows her the ability to broadcast a cancel request to miners on the network (signed with her private key). If the attacker requests to execute the transaction, verification will fail, as a cancellation block for that transaction with a valid signature has been added to the chain.
Seeing that an attacker has compromised her private key and initiated a malicious transfer (that she has cancelled), Jane needs to transfer ownership from the compromised private key to one of her retained security codes. To do this, Jane initiates a ReKey request, which executes a Knox ReKey smart contract stored on the blockchain with her initial public key (Pk0) signed by the security code (Skn) she chooses. This trusted smart contract (1) verifies that the signature is valid, (2) verifies that the Pkn is associated with Pk0 and stored on the blockchain (described in initialization), (3) verifies that the message is signed by the Skn associated with Pkn, (4) verifies that the user has not executed a previous ReKey request to Pkn. If all these criteria are met, the smart contract immediately transfers all funds to Pkn. This renders the previous private key that the attacker has stolen completely useless.
How we built it
Our submission consists of three parts: a frontend wallet app, a backend full node, and the altcoin (including its API with associated smart contracts) implemented in Solidity.
We built our frontend wallet app using Swift in XCode. It communicates with the blockchain (for now, hosted on one of our computers acting as a masternode) and formats transactions to be sent directly to the blockchain (bypassing the miner step for purposes of our HackDuke demo). It shows the user their initial security codes, stores their active private key, and notifies the user of any transactions initiated by their public key.
We built our backend full node with Flask and hosted it on Google Cloud. This backend full node continuously updates its local blockchain as communicated by our masternode (verifying that the transactions are correct using standard ERC-20 logic), maintains a mapping of public keys to transactions, and communicates with the frontend wallet application to give it an instant view of transactions associated with a public key and notifications whenever a transaction is initiated.
Challenges we ran into & What we learned
None of our teammates had ever worked seriously with blockchain technology or cryptocurrencies before. We aimed to learn as much as possible, so we took a difficult problem in a field we knew little about and tried to make something work. As a result, we spent a lot of time familiarizing ourselves each piece of how Ethereum works in practice (as well as related currencies like Bitcoin and Solana). This involved significant research into PoW, PoS, 51% attacks, hashing algorithms, ERC20, NFT trading and distribution, smart contract execution, oracles, and many more related topics. We're proud of what we've learned and what we've built in the
Our team spent quite a lot of time throwing around ideas and building the system design. Because it's a new mechanism, and because there are so many moving parts, we repeatedly found ourselves going back to the drawing board and recreating our design. As a result of that hard work, we arrived at a design we're especially proud of, and for which we see no security holes given our threat model.
Actually building these trusted Knox contracts and the core components of the coin in Solidity took our knowledge of Ethereum and put it to the test.
What's next for Knox
Right now, for the purposes of HackDuke, we assume that verifiers will correctly implement our basic verification logic (that a transaction is either an intent or an execute). Right now, we do not see a way to make this idea work on an ERC20-compliant token. Thus, an ideal next step would be pioneering a mainchain with verifiers running our custom verification logic with the slight tweaks described above.
Log in or sign up for Devpost to join the conversation.