Inspiration

This project was actually inspired by one of our team members' dad, who recently expressed frustration at the difficulty of securely sharing critical files at his job. While our team felt we'd have a relatively straightforward solution that could only be enacted using the Hedera Smart Contract Service, we had trouble committing to an entirely commercially-focused project.

That was until early March when news came out about the Russian government censoring Russian and Ukrainian citizens (https://www.nytimes.com/2022/03/04/world/europe/russia-censorship-media-crackdown.html https://time.com/6173543/world-press-freedom-index-2022/) that we realized our solution could also act as a cheap, reliable, useful tool for secure data exchange in countries under heavy censorship.

We were inspired to build a solution that would benefit both the private and enterprise sectors. Something secure, user-friendly, and reliable enough for anyone to use, but with a modular and scalable implementation that could benefit individuals, teams, or organizations of any size.

About

Traditional encryption-decryption applications require multi-party trust functions (a non-zero-trust approach), whether that's between

  • A sender and recipient (in the case of private key sharing)
  • A sender, recipient, and 3rd party (in the case of cloud/private applications)

or require absurd amounts of IT & security resources for simple file sharing.

We believe a better, easier, and more secure solution should be available by now, so we made our own!

OpenSigil is a unique zero-trust file encryption solution that runs primarily on the Hedera Smart Contract Service. Anyone with a Hashpack wallet can sign in, encrypt a file, and share the encrypted file, however, and with whomever they like.

It's up to the original file owner to decide who has the ability to decrypt their copy of the file, and access can be provided or revoked at any time.

This application is completely open-source, front-end, back-end, docker files, and even the smart contract source is available to be verified. We encourage users to explore our repository and provide comments, suggestions, and submit issues and improvements! This project is currently in the demo-only stage for the Hedera22 hackathon. It's not ready for mainnet use quite yet, but we hope to be production-ready shortly after judging is over!

How it Works

  1. A file owner selects a file to be encrypted
  2. This file is then encrypted asymmetrically using a public key generated with Fernet and Elliptic Curve Cryptography
  3. After the file is successfully encrypted, a smart contract is generated on the Hedera Smart Contract service which contains a. The sha256 hash of the encrypted file b. The owner's Hedera account id c. A list of accounts with decryption access
  4. At any point the file owner can submit an order to add/revoke decryption access to the encrypted file
  5. Whenever another user tries to decrypt a file on the platform, the application will hash the file, find the associated Hedera Contract and check if a user has decryption access
  6. If this user passes authentication, then the file is decrypted and immediately made available in it's exact original state!

Why Smart Contracts?

While our platform code is open source, it's much harder to verify our platform is running the code we say it is. And it's infeasible for trust and resource reasons to expect every user to spin up their own version each time they want to share a file. So instead, we run the code that's essential for a good user experience. But all authentication code is hosted and executed using Smart Contracts.

Smart contracts are what make OpenSigil so open (and zero trust). All computations happen remotely on a distributed and verifiable system with a guaranteed state. At any point any user can verify not just who has access, but who had access, for how long, and how that access was provided.

Any user encrypting a file can ensure their associated contract contains the proper logic and executes properly. They can also set up their own watchdog and log any interaction with their contract thanks to Hedera Mirror Nodes. And all of this happens completely separate from our application, with all operations verifiable with any compatible 3rd party network explorer or Hedera-compatible solution.

In summary, we use Smart Contracts because it's the only way to create a completely trust-less and verifiable access & authentication system.

Why Hedera?

Since our application requires Smart Contracts for zero-trust operations, we need cheap, fast transactions with as close to a 0% failure rate as possible. The Hedera Smart Contract Service is the only available distributed technology platform that can fit our needs.

Hedera contracts have

  • Extremely low fees at an avg of 1$ for contract creation and .026$ for each update transaction source
    • Compare that to 500$ for a simple Eth contract, with features like KYC raising the cost to 5 figures+ source
  • Fast, fair-ordered transactions, where it's a FIFO-based queue. Rather than the competition, which requires gas-based bribery for pitiful execution times
  • Guaranteed finality (with the appropriate gas calculation) source
  • Environmental sustainability source
    • While not essential for technical execution, the purpose of this project is to solve problems, not to create bigger ones for ourselves and future generations.

Why ECC & Fernet Encryption?

Elliptic Curve Cryptography provides cutting-edge public-key cryptography (which is required for technical execution). While certainly harder to technically implement than RSA, for private key operations such as signature generation or key management, ECC is 50-100x faster than RSA for most 256-bit operations. Yet, all asymmetric algorithms drastically lose performance with larger payload sizes, and ECC is no exception.

Instead, we use symmetric encryption to cryptographically protect file data, with ECC used to generate a public and private key based on the symmetric private key. Fernet was chosen as the best possible cipher due to its performance, minimal resource requirements, security, and ease of implementation.

How we built it

The back-end of the application runs on Django, and interfaces with a React front-end. To save time while still being attractive and user-friendly we used an application template known as react purity dashboard.

Hashconnect is used for authentication with a user's Hashpack wallet. All non-auth Hedera interactions occur on the back-end using an unofficial Python SDK. This SDK is used mostly to create, deploy, and communicate with Hedera Smart contracts, which handle all the access and authentication around users' files.

For an overall more intuitive and seamless user experience, we incorporated IPFS using Web3.storage and its HTTP API.

Finally, we incorporated SQLite as a pseudo-caching database. Deployed contracts hold a live and persistent relationship between file owners, and what other users have access to their files. However, if every time a user logs into the application, we have to query every known contract to see if this user is associated with any existing files (as an owner or accessee), our application would be incredibly expensive and inefficient.

Instead, every time a request (for access, creation, to edit access, etc.) is made to a smart contract, we log the query results and update our application DB. This keeps the Hedera Hashgraph network as a single point of truth, without sacrificing time or computation resources. (Users will always be able to manually import/export records on our homepage if they wish however)

Challenges we ran into

File Security

We needed an encryption solution that was fast, secure, and efficient. That meant crafting our own custom solution by mixing cutting-edge asymmetric and symmetric encryption methods. Unfortunately, we were a little too cutting edge, and at the time of writing, there are no good libraries for Elliptic Curve Cryptography, and especially no libraries that support mixing ECC with a modern and sleek symmetric cipher. Therefore we had to make our own from scratch based on whitepapers and unpublished books.

Time

Our team felt extremely strongly from the beginning that our submission had to be more than a proof of concept. To be truly happy with our submission we needed a live, fully-featured, hosted application for anyone to try out. This of course was quite the challenge considering the time limitations. Both our team members work full-time engineering jobs during the day and were buying and/or moving houses through the last 3 weeks of the hackathon. To compensate for this, we elected to choose core technologies we were already extremely familiar with (React for Christian as a Fullstack Dev, and Django for Bryan as a Data Engineer). As well as choosing libraries and technologies already optimized to deliver the maximum ROI as explained in the following points.

Authentication

A huge focus for us was maximizing accessibility for as many users as possible without requiring much, if any, prior knowledge of the crypto/DLT space. But offloading wallet creation and management to Hashpack, then using the Hashconnect module for authentication saved us a ton of time and energy. It's infinitely more user-friendly than anything we could create in the allotted time and adds trust and security to our application that we'd certainly be lacking otherwise.

Ease of Use

Hashpack was a huge step forward in improving the accessibility of our application to those unfamiliar with the Hedera space. But even more important was hiding the "scary" distributed technologies as much as possible. We certainly don't want to dissuade our fellow Hashgraph & Blockchain enthusiasts, but we found the average user tends to be intimidated by certain unfamiliar buzzwords and technology.

We also quickly realized that not everyone wants to manage a separate local copy of their encrypted files, and most people don't actually want to even think about what medium their file transfers occur on. This meant if we want to compete with less secure, less transparent, centralized cloud storage solutions like Dropbox, Google Drive, or OneDrive. We needed a secure, fast, distributed technology for remote file management that wouldn't require any extra brainpower on the user's part. Luckily Web3.storage was the perfect solution!

Not only was it easy to use and integrate into our platform, but the whole process was also seamless for both developers and users. Now users don't even have to download their file to share it with another person, we can handle it completely for them. Of course, hiding the really cool technical implementations made for a less "exciting" hackathon demo, but in our testing, users really appreciate the simplicity of use.

Social Good

"If you make a powerful tool, how can you be sure it gets in the hands of the people that need it most?" That was a reoccurring question on the team, that honestly, we're still struggling with, and probably will long after judging is over. But after lots of discussions, we decided the best thing we can do right now is make it as accessible as possible, and be as open to user feedback and suggestions as we can. Accessibility challenges have already been discussed at length, but it's important to note that this is greater than a good UX. Equal access is a challenge in many forms, just one of which is pricing. Trying to build a competitive business model that would allow us and others to continue to contribute to the platform, while still maximizing the number of users that can afford to encrypt a file is huge.

Hedera's aggressively cheap pricing already drives 75% of our efforts (this solution just isn't feasible on any other networks), but just bandwidth and time can be an extremely valuable resource in regions that need it most. We also need funding for hosting, development, as well as platform expansion, and scaling. This meant concerns about social good had to be incorporated into the very technology and business of our application. We hope that enterprise adoption of our application will drive feature improvements and drastic cost decreases for non-enterprise users on our platform. Including heavily discounted or free operation for certain select users or organizations.

Accomplishments that we're proud of

It works!

We got a fully functioning live version of our application for anyone to use, despite all the challenges mentioned above!

Encryption

I'm extremely proud of the encryption piece. This is something I've actually been thinking about for quite a while, but only actually attempted and got working for this hackathon. It's quite a bit outside my regular wheelhouse so getting something not just working, but working well with every file type we tried was super exciting! -Bryan

Web Development

I'm very proud of the work that we did on the frontend. My background is in full-stack development, but with most of my focus on backend & infrastructure, so while I've had experience working on the frontend this was the first time I took the lead on it. We've got some work to do, but in the short time of the hackathon, we put together a working UI that is intuitive and easy on the eyes. -Christian

Smart Contracts

Solidity development is completely new to me. Our application certainly didn't require the most advanced contract logic and expect there's plenty of room for further improvement and optimization, but it works well and reliably and I'm quite proud of that. -Bryan

Expanding our Horizons

This hackathon was a fantastic opportunity for both Bryan and me to learn new technologies and develop new skillsets. I was only vaguely familiar with the crypto ecosystem before the hackathon but was able to take the lead in researching and implementing IPFS, FileCoin, and Web3.storage which allowed me to learn so much. Bryan got to really dive deep into smart contract implementation which was the foundation of our project. He did a fantastic job and we both learned so much in the process. -Christian

Our Team

While I'm pretty proud of our project, and really looking forward to continuing development after the hackathon; I'm extra proud of my teammate Christian and the work we did together. I've been on plenty of development teams (hackathon or otherwise) but I can't think of a single time I've had more fun working on a project with someone else. Pretty much every day or so we'd send updates about our progress and were each so excited about how much work the other got done, or what a cool feature they added, or what a great idea they had. While this project and the goals we hope to achieve are extremely important to me, having such a fantastic, enthusiastic, and supportive teammate really transforms my productivity and commitment into something completely next level (Thanks for being so awesome Christian <3) -Bryan

What we learned

  • Smart contract development
  • Some unique cryptography algorithms
  • All about IPFS & Web3.storage

What's next for OpenSigil

First, we have a couple of small problems leftover from the hackathon we have to fix, but those should be solved in the next week or two. (Changes won't actually be applied until judging is over)

Once that's complete, the first big milestone we'd like to achieve is a Mainnet beta release with a small subset of users to test our application & pricing model.

Once we've solidified our QC and pricing, we'd then like to hire a 3rd party to perform a full security audit. Unfortunately, this won't be cheap but is absolutely necessary to ensure the privacy and safety of our users.

Finally, we'd like to work on enterprise-specific versions of our application, as well as work on the more challenging licensing, pricing, and certifications that come along with a commercial target.

As you can see, we're really facing more financial and business challenges than technical ones. Which is certainly a huge achievement for a hackathon project, but still daunting nonetheless. We're hoping that the financial and publicity boost that could be provided by winning the hackathon could place us in a significantly better place to tackle those financial challenges. But we're also looking into possible grants that could provide support (financial or otherwise) as well as possible investors and mentors who are willing to work closely with us to overcome many of the non-technical challenges to reach the public and enterprise markets.

Conclusion

Thank you very much for taking a look at our project!

We plan on continuing our development after the hackathon concludes, where most updates will be shared on our Github repo as linked below.

Contact

If you would like to reach out to us for any reason, (questions, comments, suggestions, business opportunities) feel free to contact us using the following methods:

Bryan Racic

Christian Tooley

Built With

Share this project:

Updates