3 ms·

Hi! I'm Guido, co-founder & CTO at Cedalio. 1. We are currently using Polygon Mumbai (testnet) and haven't enabled mainnet yet. We are testing the system with

Hi! I'm Guido, co-founder & CTO at Cedalio. 1. We are currently using Polygon Mumbai (testnet) and haven't enabled mainnet yet. We are testing the system with some customers and gradually deploying them on mainnet. We plan to launch mainnet in public access by the end of September. Cedalio works with any EVM compatible chain, we plan to add support for Polygon zkEVM and zkSync's Era network. Open to evaluate other chains as well. 2. Regarding security and failure modes, first let me give you a high level overview of how the system works, you can find more info in https://docs.cedalio.com/technology/solution-blueprint https://docs.cedalio.com/technology/solution-blueprint. Each database deployed on Cedalio stores its data off-chain and has a matching smart-contract deployed when the database is created. That smart-contract is owned by the wallet deploying the database (the end-user), we don't hold that wallet's private key. The smart-contract also has a delegate wallet, which is managed by Cedalio. We do hold the private key for the delegate address. The owner is the only one that can set who the delegate is. The delegate has full read/write access to the database. This allows our gateway to operate on behalf of the database owner. If you use Cedalio you are trusting our gateway to access your data but at any point in time you can bypass Cedalio, remove our wallet as the delegate and from that point on you can spin up your own gateway and re-route traffic to your gateway instead of ours. We think that for the use cases that we are targeting this is a reasonable trade-off. We plan to make the gateway open source by the end of the year. Regarding recovery, all mutation operations excuted against the off-chain database are replicated in an operation log that's encrypted and stored on IPFS. Only the database owner or the delegate can decrypt the operation log. If we loose the delegate keys, the owner can always recover the data even if Cedalio is not avaiable. If storing the operation log on a publicly accessible storage network like IPFS (eventhough is encrypted) is not secure enough for our user's use case, we plan to offer other storage provider (like using AWS S3 or any other solution behind a VPC). We default to IPFS for the operation log to ensure that database owner have access to the replication log and can always recover data without needing to coordinate with Cedalio. As for the encryption schema, currently we have a symetric encryption scheme but we are working on using https://litprotocol.com/ https://litprotocol.com/ for further decentralization and programability on who can decrypt the operation log. Our current solution, involves us being the ones storing and managing the private keys for the delegate wallets. Wallets are generated on per project basis and securely stored. If one wallet is compromissed, it could only access a single project not all the projects within Cedalio. That being said we are exploring two possible options to further reduce this risk. 1) using MPC wallets 2) implementing an option where you could connect a signer service, and therefore we don't need to have a delegate and the database owner is the one managing the signer infra and therefore custoding the private key. Both of these solutions have implications on devx and cost but we plan to offer them. Finally we think that our product does not have a different security risk compared to any other database saas (e.g: MongoDB Atlas, Grafbase, Heroku Postgres, etc). Meaning that we need to implement all the industry standard security meassures that any other database / saas company need to implement in other to secure its customer data. We think our use case does not compare to, lets say a blockchain brige or an exchage that has custody of the end-user token balances or any other scenario where transactions cannot be reversed. In our case, the only thing that we are storing on the smart-contract is the database's ACL and the hash/CID of the latest operation commited into the operation log. Data can be recovered. That being said, the risk of being hacked is that if an attacker gains access to a database delegate wallet private key, they can access the user's data but this is the same risk any other database / SaaS company has. Let me know if there is anything that needs clarification.

theamk 3y ago
You have completely missed my point -- I have no doubt your security is good, after all you specialize on blockchains and know how to manage them. But your security mechanisms work by pushing out all responsibility onto customers, the same customers who are not blockchain experts, and who have occasional problems even with seemingly simple things. Even a tech giant like microsoft.com have forgotten to renew DNS domains a few times... would you really expect a random industry company to keep their primary wallet safe forever? And this is where the weakness of blockchain lies: if a hacker steals AWS root credentials, no problem - a phone call/support email will get them changed, or AWS might detect unusual patterns and lockout account preventively. There might be some data stolen or deleted before this happens, but once credentials are restored it's business can continue as usual. While if the primary wallet is stolen, it is game over, customer's only recourse is to (1) accept the entire database is leaked.. even if the hacker did not download entire thing yet, they have all the time in the word to do so, it's not like you can revoke the key (2) accept the database is not usable anymore, and they need to clone it under a new wallet and update all the clients. And sure, you can blame the customer but that's not going to matter much if you are competing with AWS or any other big cloud provider which does not have such weakness.
- guidomb 3y ago
  I totally agree with your perspective and the current state of affair regarding ux in the blockchain / web3 space is what in part motivated us to create Cedalio. The mechanisim that we've built so far is to let the database owner be the one securing the private key because is the basic feature that needs to exist to built everything on top of and because we were first targeting developers in the web3 space, who value having this option. For use cases where the end-user is not technical or security-savy enough (99% of users probably) we are providing other options. We support authentication via Privy.io that enables users to create an account with username / password or connect their other login accounts (Google, GitHub, etc) and never have to worry about managing keys. For more info check https://docs.privy.io/guide/frontend/embedded/overview https://docs.privy.io/guide/frontend/embedded/overview. That being said we want to offer more auth providers and make life easier for users that don't want to manage their own private keys, we haven't launch access to mainnet yet. For example providing MPC wallet for end-users as well. There are other mechanisim for account recovery as well, like social recovery that could be implemented. As for your main point regarding business continuity and data leakage, our current solution allows us to recover the database because we have several backup mechanisims in place. That being said, as you pointed out, if the operation log is stored on a publicly accessible decentralized storage network and if an attacker gains access to the decryption keys then yes data will be leaked. Similar to how any application developer could get their AWS API keys leaked and a database is copied (assuming the database is not encrypted at rest). The current alterantive to this attack vector (if data ownership / portability without having to interact with Cedalio is not required) is to choose other storage solutions for the operation log. This is on our roadmap. We are also exploring encryption using lit.protocol and making the decryption access programmable which would allow us to remove access to who can decrypt the operation log and the encryption keys would be stored by the protocol not by the end-user. Therefore is a user looses their keys, we can remove that wallet from the list of wallets that can decrypt the operation log.

theamk 3y ago

You have completely missed my point -- I have no doubt your security is good, after all you specialize on blockchains and know how to manage them. But your security mechanisms work by pushing out all responsibility onto customers, the same customers who are not blockchain experts, and who have occasional problems even with seemingly simple things. Even a tech giant like microsoft.com have forgotten to renew DNS domains a few times... would you really expect a random industry company to keep their primary wallet safe forever? And this is where the weakness of blockchain lies: if a hacker steals AWS root credentials, no problem - a phone call/support email will get them changed, or AWS might detect unusual patterns and lockout account preventively. There might be some data stolen or deleted before this happens, but once credentials are restored it's business can continue as usual. While if the primary wallet is stolen, it is game over, customer's only recourse is to (1) accept the entire database is leaked.. even if the hacker did not download entire thing yet, they have all the time in the word to do so, it's not like you can revoke the key (2) accept the database is not usable anymore, and they need to clone it under a new wallet and update all the clients. And sure, you can blame the customer but that's not going to matter much if you are competing with AWS or any other big cloud provider which does not have such weakness.

guidomb 3y ago
I totally agree with your perspective and the current state of affair regarding ux in the blockchain / web3 space is what in part motivated us to create Cedalio. The mechanisim that we've built so far is to let the database owner be the one securing the private key because is the basic feature that needs to exist to built everything on top of and because we were first targeting developers in the web3 space, who value having this option. For use cases where the end-user is not technical or security-savy enough (99% of users probably) we are providing other options. We support authentication via Privy.io that enables users to create an account with username / password or connect their other login accounts (Google, GitHub, etc) and never have to worry about managing keys. For more info check https://docs.privy.io/guide/frontend/embedded/overview https://docs.privy.io/guide/frontend/embedded/overview. That being said we want to offer more auth providers and make life easier for users that don't want to manage their own private keys, we haven't launch access to mainnet yet. For example providing MPC wallet for end-users as well. There are other mechanisim for account recovery as well, like social recovery that could be implemented. As for your main point regarding business continuity and data leakage, our current solution allows us to recover the database because we have several backup mechanisims in place. That being said, as you pointed out, if the operation log is stored on a publicly accessible decentralized storage network and if an attacker gains access to the decryption keys then yes data will be leaked. Similar to how any application developer could get their AWS API keys leaked and a database is copied (assuming the database is not encrypted at rest). The current alterantive to this attack vector (if data ownership / portability without having to interact with Cedalio is not required) is to choose other storage solutions for the operation log. This is on our roadmap. We are also exploring encryption using lit.protocol and making the decryption access programmable which would allow us to remove access to who can decrypt the operation log and the encryption keys would be stored by the protocol not by the end-user. Therefore is a user looses their keys, we can remove that wallet from the list of wallets that can decrypt the operation log.