0

In most cases, I would assume that if your wallet is compromised, your funds are going to be stolen and that is how you are going to know it is compromised. However, let's assume a hypothetical threat actor get's your private keys, and then restores the wallet without making any transactions (without stealing). As an example as to why a threat actor might do this, let's assume that you only have 100 Ada in your wallet and they think you'll deposit more into it later on. In other words, they are going to wait it out hoping to steal more.

My question is: Is there currently a way to know if someone has restored/accessed your wallet without them creating a transaction with your keys?

My understanding is that there is not, so if that is true, my next question is: What could be done, potentially a CIP, that could mitigate this?

2

Cardano uses the Hierarchical Deterministic key generation scheme (specifically that of BIP44-ed25519), which is an offline process that can be done without an internet connection. As such, there is no way to know that your master key has been compromised unless it is used to submit a transaction. However, clever use of NFTs and Plutus scripts enable us to construct a variety of risk-management protocols with associated trade-offs. Even simple constructions as outlined here may be used create highly complex output gaurds.

A super simple example is that of a "death protection" scheme that I use with my family. My primary key is under my secure control, but in the event that key becomes inaccessible, there is a second, highly accessible key that is only unlocked 10 years from now. Here's the JSON formula I use to build the script-address:

{
  "type": "any",
  "scripts":
  [
    {
      "type": "sig",
      "keyHash": "<PRIMARY KEYHASH>"
    },
    {
      "type": "all",
      "scripts":
      [
        {
          "type": "after",
          "slot": <FUTURE SLOT NUMBER>
        },
        {
          "type": "sig",
          "keyHash": "<EMERGENCY KEYHASH>"
        }
      ]
    }
  ]
}

However, no matter the complexity/design of your scheme, a permissionless blockchain without trusted third-parties will NEVER protect you against catastrophic loss of a master secret.

The only real way around this is to admit some form of centralization/third-party authentication. The question then becomes, in what form should such insurances be?

IOHK actually wrote this paper about "proofs-of-ownership" and "secure hidden fallback" mechanisms that may be leveraged for such purposes.

Quick Summary:

A back-up key can be created upstream of the initial key derivation; one that is never used, even for signing transactions. The only time one would use it is to prove ownership of a child signing key. Ideally, such keys would never see the light of a network and would be kept separate from the primary signing keys. These back-up keys can be used to prove ownership of their associated wallets. This can be extremely useful in the event a (side)chain is rolled back due to some massive security flaw, among other scenarios.

2
  • Thanks for the response! Do you happen to have a write up of the details of this death protection scheme, I am very interested in that. So the Plutus script time locks were the kind of thing I was envisioning for this type of protection. I was just wondering if there would be a way to build that into the protocol and if it would be worth it. I am more thinking along the lines of proof of access vs proof of ownership. I do understand there is no way to detect offline access. Nov 28 '21 at 23:15
  • 1
    No problem! I edited the original answer to include the death-protection scheme.
    – nomad0
    Nov 28 '21 at 23:31
1

There is no such thing as wallet-restoral or even initialization on the blockchain. These are purely client-side events happening on the device of the user. As such, there is no way to check if someone in the world has setup a wallet with your keys.

However, what follows after a wallet is set up is that it queries the connected node for available funds. I’m pretty sure that a standard node such as the one from Yoroi does not track which funds of which keys have been queried. But in principle this would be the action that would be traceable. If the thief checks your funds on his own node, however, (for example in Daedalus) there is truely no way to trace this.

8
  • This is pretty much what my understanding of this was as well. Do you know why there isn't any kind of wallet restoration event recorded on the blockchain? I realize solutions to this could get complicated really quickly but I guess I am wondering if it is a 'not worth the effort' or if there is a technical reason why a restoration event isn't recorded (I also didn't see any other blockchains that do this either). Maybe the additional transaction fees aren't worth this little benefit? Nov 28 '21 at 22:52
  • I'd imagine that any sort of "restoration" mechanic poses a massive risk to the legitimacy of a chain because people would abuse it themselves.
    – nomad0
    Nov 28 '21 at 22:59
  • @nomad0, could you give an example of abuse for this? Nov 28 '21 at 23:06
  • Sorry for not clarifying, I imagine something along the lines of: I pay you for a legitimate product/service, then claim the transaction was unauthorized and attempt to rollback. Many systems can compensate for this, such as you (the vendor) being able to challenge my rollback request. But now we need arbiters, and things get real weird real quick.
    – nomad0
    Nov 28 '21 at 23:14
  • Oh yeah that makes a lot of sense. So I am not thinking proof of ownership as much as just proof of access. Thinking along the lines of a wallet is restored and there is a time lock on the use for that specific restoration (not exactly sure how this would work, maybe mac addresses?). This would allow someone to create a watch service that you subscribe to, to know someone restored the wallet. This would give you time to save your funds while the time lock was active. Nov 28 '21 at 23:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.