commit 915b02988ad48c6cb39a1101354dd9e596c784ed
parent 28d42de585e69f85687b06ff7e3388babcd50e50
Author: Christian Grothoff <grothoff@gnunet.org>
Date: Mon, 4 Aug 2025 11:24:24 +0200
add data protection concept
Diffstat:
2 files changed, 54 insertions(+), 1 deletion(-)
diff --git a/manpages/taler-exchange.conf.5.rst b/manpages/taler-exchange.conf.5.rst
@@ -97,6 +97,10 @@ CURRENCY_ROUND_UNIT
DB
Plugin to use for the database, e.g. “postgres”.
+ATTRIBUTE_ENCRYPTION_KEY
+ Attribute encryption key for storing attributes encrypted
+ in the database. Should be a high-entropy nonce.
+
SERVE
Should the HTTP server listen on a UNIX domain socket (set option to "unix"), or on a TCP socket (set option to "tcp"), or be activated via systemd (set option to "systemd").
@@ -697,7 +701,7 @@ RATER_COMMAND
MIN_ROW_FILENAME
Name of the file where taler-exchange-sanctionscheck will store the
- last row process during sanction list evaluation. Not in the database
+ last row process during sanction list evaluation. Not in thed atabase
as we frequently need to reset it when we get a new list, so no
transactionality is needed or even desirable. There should be no
need to change the default.
diff --git a/taler-exchange-manual.rst b/taler-exchange-manual.rst
@@ -639,6 +639,55 @@ Finally we need to grant the other accounts limited access:
``taler-exchange-dbinit`` tool cannot setup these permissions, as it
does not know which users will be used for which processes.
+.. _Dataprotection:
+
+Data protection concept
+-----------------------
+
+The ``kyc-attributes`` table contains the most sensitive
+data, namely the KYC records of the recipients of payments.
+The data could include passports, business documentation
+and other sensitive information. At a high-level, it is
+stored in JSON format (key-value), compressed and then
+additionally encrypted using a secret key from the
+exchange configuration (the ``ATTRIBUTE_ENCRYPTION_KEY``).
+Thus, this data is protected even if the full database
+is leaked.
+
+The ``aml-history`` table stores the main information
+provided by AML officers. This may contain sensitive
+data about risk assessments on customers, exposed or
+secret limits imposed on individual accounts, and
+in general forms supplied by bank staff. AML decisions
+are also tracked in the ``legitimization-*`` tables,
+including the latest rules that apply to an account.
+
+The second most sensitive table is
+``wire-targets``, as it contains the IBANs (and possibly
+other visible information from RFC 8905) of the bank
+accounts of the customers. Many other tables contain
+transaction data (incoming, outgoing, p2p transfers,
+etc) which are somewhat less sensitive. It should be
+noted that the actual contracts between customers and
+merchants are not available to the exchange operator;
+the ``contracts`` table only stores contracts for p2p
+transfers in an end-to-end encrypted format that the
+exchange itself can never decrypt.
+
+The database is periodically cleaned up via the
+``taler-exchange-dbinit --gc`` command. It is
+currently hard-coded (!) to delete KYC/AML data
+of accounts that have been inactive for 10 years.
+
+Data on incoming wire transfers (reserves) is
+deleted after the ``LEGAL_RESERVE_EXPIRATION_TIME``
+is reached, as configured in the ``[exchangedb]``
+section. The default is set to 7 years.
+
+Payment data is deleted whenever the legal expiration date for the
+``DURATION_LEGAL`` configured in the respective section ``coin`` is reached
+(typically also after 10 years).
+
Basic Setup: Currency, Denominations and Keys
=============================================
