View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005536 | Taler | exchange | public | 2019-01-31 23:42 | 2019-12-20 19:12 |
| Reporter | Christian Grothoff | Assigned To | Christian Grothoff | ||
| Priority | high | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | fixed | ||
| Platform | i7 | OS | Debian GNU/Linux | OS Version | squeeze |
| Product Version | git (master) | ||||
| Target Version | 0.6 | Fixed in Version | 0.6 | ||
| Summary | 0005536: exchange should delete private keys after signing period expires | ||||
| Description | Right now, the private keys remain on disk and thus the compromise window still exists. We should modify the code to automatically (!) delete (overwrite file with random bits, then unlink()) private key material. For this, it'll also be required to define additional files that just contain the public keys, as the time frame during which we may need to verify signatures created with our private keys is often much longer. (This is about both RSA keys as well as EdDSA signing keys.) | ||||
| Tags | No tags attached. | ||||
|
|
Todo: 1) EXCHANGEDB needs to implement new get_denomination_info() call 2) httpd_keystate.c needs to implement reload_public_denoms_cb() 3) httpd_keystate.c needs to deal with some DKIs possibly NOT having a private key; 4) rest of code should be checked to also be graceful about DKIs NOT having a private key sometimes 5) actual deletion of denom priv key files should be implemented 6) actual deletion of online signing key private key files should be implemented |
|
|
1) implemented in 079207a4..1a542148 |
|
|
I've checked (4), added a few assertions in 88e611d32b7ce7adda7fde271c62f7ffb8c6f1fe, but no issues were found. |
|
|
ec3a4aad..9fb88940 adds the logic for (2) and (3), but effectively commented out via an "if (0)" as the test_exchange_api_new fails with it on for unknown reasons. (5) and (6) are not yet even implemented, so this is particularly strange. |
|
|
Right now, denomination key revocations are stored in ".rev" files that only contain the signature and depend on the existence of the base file (without '.rev') with the private key. If we delete that private key file, the revocation will also be lost (bad). Furthermore, there is actually no reason to keep the revocations in files instead of the exchange database. So we should change this and move the revocation file content into exchangedb! |
|
|
9fb88940..62e8c183 fixes 0005536:0013838 (we simply had to check in the revoked key map as well before, least we end up with DKs in both the revoked and active maps). Before implementing (5) we need to still address 0005536:0013840. |
|
|
Just noticed that the table denomination_revocations exist, so why are we using the .rev files? |
|
|
Ok, so right now taler-exchange-keyup generates the '.rev' file, and then upon SIGHUP the exchange finds it and puts it into the database. This was done because taler-exchange-keyup has access to the offline master private key, and thus NOT to the (online) database. That split should probably be preserved, which means a ".rev" file should be generated. But what we could do is (1) include the denom hash in the .rev file, so it can be associated with a denomination key even without the convention of the filename, (2) scan for revocations from the DB in addition to those in .rev files (so that if the .rev file is lost, we still remember). If a .rev exists but the DB transaction fails (denom pub hash unknown) we right now fail hard, that should probably be softened (least the exchange dies because of a single bogus file on disk). |
|
|
a9268421d79b30c9af5be12d2d902abcd363a60b completes (4) -- including new rev file format, etc. -- and (5) and (6). |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-01-31 23:42 | Christian Grothoff | New Issue | |
| 2019-01-31 23:42 | Christian Grothoff | Status | new => assigned |
| 2019-01-31 23:42 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2019-01-31 23:42 | Christian Grothoff | Description Updated | |
| 2019-02-14 13:31 | Christian Grothoff | Note Added: 0013756 | |
| 2019-02-16 21:38 | Christian Grothoff | Note Added: 0013834 | |
| 2019-02-16 23:53 | Christian Grothoff | Note Added: 0013836 | |
| 2019-02-17 00:28 | Christian Grothoff | Note Added: 0013838 | |
| 2019-02-17 14:39 | Christian Grothoff | Note Added: 0013840 | |
| 2019-02-17 14:42 | Christian Grothoff | Note Added: 0013841 | |
| 2019-02-17 20:18 | Christian Grothoff | Note Added: 0013851 | |
| 2019-02-17 20:25 | Christian Grothoff | Note Added: 0013853 | |
| 2019-03-11 03:44 | Christian Grothoff | Note Added: 0014179 | |
| 2019-03-11 03:45 | Christian Grothoff | Fixed in Version | => 0.6 |
| 2019-03-11 03:45 | Christian Grothoff | Target Version | 0.8 => 0.6 |
| 2019-03-11 03:45 | Christian Grothoff | Status | assigned => resolved |
| 2019-03-11 03:45 | Christian Grothoff | Resolution | open => fixed |
| 2019-12-20 19:12 | Christian Grothoff | Status | resolved => closed |
