user4382: 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?

user2537: 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.

user4302: 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.

4382: <p>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.</p>
<p>My question is: <strong>Is there currently a way to know if someone has restored/accessed your wallet without them creating a transaction with your keys?</strong></p>
<p>My understanding is that there is not, so if that is true, my next question is: <strong>What could be done, potentially a <a href="https://github.com/cardano-foundation/CIPs" rel="nofollow noreferrer">CIP</a>, that could mitigate this?</strong></p>
 2537: <p>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.</p>
<p>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.</p>
 4302: <p>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 <a href="https://github.com/input-output-hk/cardano-node/blob/master/doc/reference/simple-scripts.md" rel="nofollow noreferrer">here</a> may be used create highly complex output gaurds.</p>
<p>A super simple example is that of a &quot;death protection&quot; 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:</p>
<pre><code>{
  &quot;type&quot;: &quot;any&quot;,
  &quot;scripts&quot;:
  [
    {
      &quot;type&quot;: &quot;sig&quot;,
      &quot;keyHash&quot;: &quot;&lt;PRIMARY KEYHASH&gt;&quot;
    },
    {
      &quot;type&quot;: &quot;all&quot;,
      &quot;scripts&quot;:
      [
        {
          &quot;type&quot;: &quot;after&quot;,
          &quot;slot&quot;: &lt;FUTURE SLOT NUMBER&gt;
        },
        {
          &quot;type&quot;: &quot;sig&quot;,
          &quot;keyHash&quot;: &quot;&lt;EMERGENCY KEYHASH&gt;&quot;
        }
      ]
    }
  ]
}
</code></pre>
<p>However, no matter the complexity/design of your scheme, a permissionless blockchain <em><strong>without</strong></em> trusted third-parties will <strong>NEVER</strong> protect you against catastrophic loss of a master secret.</p>
<p>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?</p>
<p>IOHK actually wrote <a href="https://iohk.io/en/research/library/papers/w-otsup-my-sleevea-hidden-secure-fallback-for-cryptocurrency-wallets/" rel="nofollow noreferrer">this</a> paper about &quot;proofs-of-ownership&quot; and &quot;secure hidden fallback&quot; mechanisms that may be leveraged for such purposes.</p>
<p><strong>Quick Summary:</strong></p>
<p>A <em>back-up key</em> 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.</p>
