View Issue Details

IDProjectCategoryView StatusLast Update
0005536Talerexchangepublic2019-03-11 03:45
ReporterChristian GrothoffAssigned ToChristian Grothoff 
PriorityhighSeverityfeatureReproducibilityN/A
Status resolvedResolutionfixed 
Platformi7OSDebian GNU/LinuxOS Versionsqueeze
Product VersionSVN HEAD 
Target Version0.6Fixed in Version0.6 
Summary0005536: exchange should delete private keys after signing period expires
DescriptionRight 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.)
TagsNo tags attached.

Activities

Christian Grothoff

2019-02-14 13:31

manager   ~0013756

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

Christian Grothoff

2019-02-16 21:38

manager   ~0013834

1) implemented in 079207a4..1a542148

Christian Grothoff

2019-02-16 23:53

manager   ~0013836

I've checked (4), added a few assertions in 88e611d32b7ce7adda7fde271c62f7ffb8c6f1fe, but no issues were found.

Christian Grothoff

2019-02-17 00:28

manager   ~0013838

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.

Christian Grothoff

2019-02-17 14:39

manager   ~0013840

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!

Christian Grothoff

2019-02-17 14:42

manager   ~0013841

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.

Christian Grothoff

2019-02-17 20:18

manager   ~0013851

Just noticed that the table denomination_revocations exist, so why are we using the .rev files?

Christian Grothoff

2019-02-17 20:25

manager   ~0013853

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).

Christian Grothoff

2019-03-11 03:44

manager   ~0014179

a9268421d79b30c9af5be12d2d902abcd363a60b completes (4) -- including new rev file format, etc. -- and (5) and (6).

Issue History

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 View Revisions
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