.. This file is part of GNU TALER. Copyright (C) 2014-2020 Taler Systems SA TALER is free software; you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation; either version 2.1, or (at your option) any later version. TALER is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details. You should have received a copy of the GNU Affero General Public License along with TALER; see the file COPYING. If not, see @author Christian Grothoff GNU Taler Exchange Operator Manual ################################## Introduction ============ This manual is an early draft that still needs significant editing work to become readable. About GNU Taler --------------- GNU Taler is an open protocol for an electronic payment system with a free software reference implementation. GNU Taler offers secure, fast and easy payment processing using well understood cryptographic techniques. GNU Taler allows customers to remain anonymous, while ensuring that merchants can be held accountable by governments. Hence, GNU Taler is compatible with anti-money-laundering (AML) and know-your-customer (KYC) regulation, as well as data protection regulation (such as GDPR). GNU Taler is not yet production-ready, after following this manual you will have a backend that can process payments in “KUDOS”, but not regular currencies. This is not so much because of limitations in the backend, but because we are not aware of a Taler exchange operator offering regular currencies today. About this manual ----------------- This tutorial targets system administrators who want to install and operate a GNU Taler exchange. Organizational prerequisites ---------------------------- Operating a GNU Taler exchange means that you are operating a payment service provider, which means that you will most likely need a bank license and/or follow applicable financial regulation. GNU Taler payment service providers generally need to ensure high availability and have *really* good backups (synchronous replication, asynchronous remote replication, off-site backup, 24/7 monitoring, etc.). This manual will not cover these aspects of operating a payment service provider. We will assume that you can operate a (high-availability, high-assurance) Postgres database. Furthermore, we expect some moderate familiarity with the compilation and installation of free software packages. You need to understand the cryptographic concepts of private and public keys and must be able to protect private keys stored in files on disk. .. include:: frags/db-stores-sensitive-data.rst Architecture overview --------------------- Taler is a pure payment system, not a new crypto-currency. As such, it operates in a traditional banking context. In particular, this means that in order to receive funds via Taler, the merchant must have a regular bank account, and payments can be executed in ordinary currencies such as USD or EUR. Similarly, the Taler exchange must interact with a bank. The bank of the exchange holds the exchange’s funds in an escrow account. Note that, given the technical burden (XML-based communications, additional cryptography, and a vast variety of standards) due to interact with banks, the exchange uses a intermediary system to talk to its bank. Such intermediary system abstracts the native banking protocol by exposing the *Taler Wire Gateway API*; this way, the exchange can conduct its banking operations in a simplified and JSON-based style. When customers wire money to the escrow account, the bank notifies the exchange about the incoming wire transfers. The exchange then creates a *reserve* based on the subject of the wire transfer. The wallet which knows the secret key matching the wire transfer subject can then withdraw coins from the reserve, thereby draining it. The liability of the exchange against the reserve is thereby converted into a liability against digital coins issued by the exchange. When the customer later spends the coins at a merchant, and the merchant *deposits* the coins at the exchange, the exchange first *aggregates* the amount from multiple deposits from the same merchant and then instructs its bank to make a wire transfer to the merchant, thereby fulfilling its obligation and eliminating the liability. The exchange charges *fees* for some or all of its operations to cover costs and possibly make a profit. *Auditors* are third parties, for example financial regulators, that verify that the exchange operates correctly. The same software is also used to calculate the exchange’s profits, risk and liabilities by the accountants of the exchange. The Taler software stack for an exchange consists of the following components: - HTTP frontend The HTTP frontend interacts with Taler wallets and merchant backends. It is used to withdraw coins, deposit coins, refresh coins, issue refunds, map wire transfers to Taler transactions, inquire about the exchange’s bank account details, signing keys and fee structure. The binary is the ``taler-exchange-httpd``. - Crypto-Helpers The ``taler-exchange-secmod-rsa`` and ``taler-exchange-secmod-eddsa`` are two programs that are responsible for managing the exchange's online signing keys. They must run on the same machine as the ``taler-exchange-httpd`` as the HTTP frontend communicates with the crypto helpers using UNIX Domain Sockets. - Aggregator The aggregator combines multiple deposits made by the same merchant and (eventually) triggers wire transfers for the aggregate amount. The merchant can control how quickly wire transfers are made. The exchange may charge a fee per wire transfer to discourage excessively frequent transfers. The binary is the ``taler-exchange-aggregator``. - Closer The ``taler-exchange-closer`` tool check that reserves are properly closed. If a customer wires funds to an exchange and then fails to withdraw them, the closer will (eventually) trigger a wire transfer that sends the customer's funds back to the originating wire account. - Transfer The ``taler-exchange-transfer`` tool is responsible for actually executing the aggregated wire transfers. It is the only process that needs to have the credentials to execute outgoing wire transfers. The tool uses the Taler Wire Gateway API to execute wire transfers. This API is provided by the Taler Python Bank for stand-alone deployments (like those with ``KUDOS``) and by LibEuFin. LibEuFin is an adapter which maps the Taler Wire REST API to traditional banking protocols like EBICS and FinTS. - Wirewatch The ``taler-exchange-wirewatch`` tool is responsible for observing incoming wire transfers to the exchange. It needs to have the credentials to obtain a list of incoming wire transfers. The tool also uses the Taler Wire Gateway API to observe such incoming transfers. It is possible that observing incoming and making outgoing wire transfers is done via different bank accounts and/or credentials. - Wire adapter A wire adapter is a component that enables exchange to talk to a bank. (1) The libtalerfakebank implements a bank with a wire adapter API inside of a testcase. (2) For the demonstration Web site (or local currencies), the Python bank provides a bank that directly provides the wire adapter API. (3) For production, libeufin's Nexus component implements a wire adapter towards the traditional SEPA banking system with IBAN accounts. The client-side wire adapter API is implemented in libtalerbank and is used by the transfer to execute wire transfers and for the auditor to query bank transaction histories. - DBMS The exchange requires a DBMS to stores the transaction history for the Taler exchange and aggregator, and a (typically separate) DBMS for the Taler auditor. For now, the GNU Taler reference implementation only supports Postgres, but the code could be easily extended to support another DBMS. .. index:: Postgres - Auditor The auditor verifies that the transactions performed by the exchange were done properly. It checks the various signatures, totals up the amounts and alerts the operator to any inconsistencies. It also computes the expected bank balance, revenue and risk exposure of the exchange operator. The main binary is the ``taler-auditor``. Aside from the key setup procedures, the most critical setup for deploying an auditor is providing the auditor with an up-to-date copy of the database. Offline keys ------------ The exchange (and ideally also auditors) uses a long-term offline master siging key that identifies the operator and is used to authenticate critical information, such as the exchange's bank account and the actual keys the exchange uses online. Interactions with the offline system are performed using the ``taler-exchange-offline`` tool. To use the offline system will require exchange operators to copy JSON files from or to the offline system (say using an USB stick). The offline system does not need any significant amount of computing power, a Raspberry-Pi is perfectly sufficient and the form-factor might be good for safe-keeping! (You should keep a copy of the (encrypted) private offline key on more than one physical medium though.) Exchange operators are strongly advised to secure your private master key and any copies on encrypted, always-offline computers. Again, we assume that you are familiar with good best practices in operational security, including securing key material. Online signing key security --------------------------- To provide an additional level of protection for the private *online* signing keys used by the exchange, the actual cryptographic signing operations are performed by two helper processes, the ``taler-exchange-secmod-rsa`` and the ``taler-exchange-secmod-eddsa``. The current implementation does not yet support the use of a hardware security module (HSM). If you have such a device with adequate functionality and are interested in Taler supporting it, please contact the developers for HSM integration support. Functionality ^^^^^^^^^^^^^ The UNIX domain sockets have mode 0620 (u+rw, g+w). The exchange process MUST be in the same group as the crypto helper processes. The two helper processes will create the required private keys, and allow anyone with access to the UNIX domain socket to sign arbitrary messages with the keys or to inform them about a key being revoked. The helper processes are also responsible for deleting the private keys if their validity period expires or if they are informed about a key having been revoked. Security goals ^^^^^^^^^^^^^^ From a security point of view, the helpers are designed to *only* make it harder for an attacker who took control of the HTTP daemon's account to extract the private keys, limiting the attackers ability to creating signatures to the duration of their control of that account. .. note:: In the future, the helper processes should additionally provide a mechanism to track the total number of signatures they have made for the various keys. Setup ^^^^^ The helper processes should be run under a user ID that is separate from that of the user running the main ``taler-exchange-httpd`` service. For security, it is important that helpers run under a different user ID than the main HTTP frontend, in fact ideally each helper should run under its own user ID. The ``taler-exchange-httpd`` service's will securely communicate with the helpers using UNIX domain sockets. To enable access to the keys, the service's user must be in the group of the helper processes (and no other users should be in that group). Configuration ^^^^^^^^^^^^^ The helpers and the HTTP service need both access to the same configuration information. Having divergent configurations may result in run-time failures. It is recommended that the configuration file (``-c`` option) is simply shared between all of the different processes, even though they run as different system users. The configuration does not contain any sensitive information. Installation ============ Before installing a Taler exchange, please make sure that your system does not have swap space enabled. Swap space is a security risk that Taler does not try to mitigate against. Please install the following packages before proceeding with the exchange compilation. .. include:: frags/list-of-dependencies.rst - GNU Taler exchange (from `download directory `__, see `release announcement `__) Except for the last two, these are available in most GNU/Linux distributions and should just be installed using the respective package manager. Installing from source ---------------------- The following instructions will show how to install libgnunetutil and the GNU Taler exchange from source. .. include:: frags/installing-gnunet.rst .. include:: frags/installing-taler-exchange.rst Installing the GNU Taler binary packages on Debian -------------------------------------------------- .. include:: frags/installing-debian.rst To install the Taler exchange, you can now simply run: .. code-block:: console # apt install -t sid taler-exchange Note that the package does not perform any configuration work except for setting up the various users and the systemd service scripts. You still must configure at least the database, HTTP reverse proxy (typically with TLS certificates), denomination and fee structure, bank account, auditor(s), offline signing and the terms of service. Sample configuration files for the HTTP reverse proxy can be found in ``/etc/taler-exchange/``. Installing the GNU Taler binary packages on Ubuntu -------------------------------------------------- .. include:: frags/installing-ubuntu.rst To install the Taler exchange, you can now simply run: .. code-block:: console # apt install -t focal-fossa taler-exchange Note that the package does not perform any configuration work except for setting up the various users and the systemd service scripts. You still must configure at least the database, HTTP reverse proxy (typically with TLS certificates), denomination and fee structure, bank account, auditor(s), offline signing and the terms of service. Sample configuration files for the HTTP reverse proxy can be found in ``/etc/taler-exchange/``. Configuration ============= This chapter provides an overview of the exchange configuration. Or at least eventually will do so, for now it is a somewhat wild description of some of the options. .. include:: frags/configuration-format.rst .. _Using-taler_002dconfig-exchange: .. include:: frags/using-taler-config.rst .. _Keying: Keying ------ The exchange works with four types of keys: - master key (kept offline) To create a master key, use: .. code-block:: console $ taler-exchange-offline setup - sign keys (signs normal messages from the exchange) - denomination keys (signs electronic coins, see section Coins) - security module keys (signs sign keys and denomination keys) Additionally, the exchange is sometimes concerned with the auditor's public key (to verify messages signed by auditors approved by the exchange operator) and the merchant's public key (to verify refunds are authorized by the merchant). Key options include: - ``[exchange-offline/MASTER_PRIV_FILE]``: Path to the exchange’s master private file. Only needs to be provided on the offline system where the ``taler-exchange-offline`` command is used. - ``[exchange/MASTER_PUBLIC_KEY]``: Must specify the exchange’s master public key. Needed for the exchange to verify information signed by the offline system. .. _Serving: Serving ------- The exchange can serve HTTP over both TCP and UNIX domain socket. The following options are to be configured in the section ``[exchange]``: - ``SERVE``: Must be set to ``tcp`` to serve HTTP over TCP, or ``unix`` to serve HTTP over a UNIX domain socket. - ``PORT``: Set to the TCP port to listen on if ``SERVE`` is ``tcp``. - ``UNIXPATH``: Set to the UNIX domain socket path to listen on if ``SERVE`` is ``unix``. - ``UNIXPATH_MODE``: Number giving the mode with the access permission mask for the ``UNIXPATH`` (i.e. 660 = ``rw-rw---``). .. _Currency: Currency -------- The exchange supports only one currency. This data is set under the respective option ``CURRENCY`` in section ``[taler]``. .. _Database: Database -------- The option ``DB`` in section ``[exchange]`` gets the database backend’s name the exchange is going to use. So far, only ``db = postgres`` is supported. After choosing the backend, it is mandatory to supply the connection string (namely, the database name). This is possible in two ways: - via an environment variable: ``TALER_EXCHANGEDB_POSTGRES_CONFIG``. - via configuration option ``CONFIG``, under section ``[exchangedb-$BACKEND]``. For example, the demo exchange is configured as follows: .. code-block:: ini [exchange] ... DB = postgres ... [exchangedb-postgres] CONFIG = postgres:///talerdemo Given this database configuration, the database can be initialized using: .. code-block:: console $ taler-exchange-dbinit Note that to run this command, the user must have ``CREATE TABLE``, ``CREATE INDEX``, ``ALTER TABLE`` and (in the future possibly even) ``DROP TABLE`` permissions. Those permissions are only required for this step (which may have to be repeated when upgrading a deployment). Afterwards, during normal operation, permissions to ``CREATE`` or ``ALTER`` tables are not required by any of the Taler exchange processes and thus should not be granted. For more information, see :doc:`manpages/taler-exchange-dbinit.1`. Commands, like ``taler-exchange-dbinit``, that support the ``-l LOGFILE`` command-line option, send logging output to standard error by default. .. _Coins-denomination-keys: Coins (denomination keys) ------------------------- Sections specifying denomination (coin) information start with ``coin_``. By convention, the name continues with ``$CURRENCY_[$SUBUNIT]_$VALUE_$REVISION``, i.e. ``[coin_eur_ct_10_0]`` for a 10 cent piece. However, only the ``coin_`` prefix is mandatory. Once configured, these configuration values must not change. The ``$REVISION`` part of the section name should be incremented if any of the coin attributes in the section changes. Each ``coin_``-section must then have the following options: - ``VALUE``: How much is the coin worth, the format is CURRENCY:VALUE.FRACTION. For example, a 10 cent piece is "EUR:0.10". - ``DURATION_WITHDRAW``: How long can a coin of this type be withdrawn? This limits the losses incurred by the exchange when a denomination key is compromised. - ``DURATION_SPEND``: How long is a coin of the given type valid? Smaller values result in lower storage costs for the exchange. - ``DURATION_LEGAL``: How long is the coin of the given type legal? - ``FEE_WITHDRAW``: What does it cost to withdraw this coin? Specified using the same format as value. - ``FEE_DEPOSIT``: What does it cost to deposit this coin? Specified using the same format as value. - ``FEE_REFRESH``: What does it cost to refresh this coin? Specified using the same format as value. - ``FEE_REFUND``: What does it cost to refund this coin? Specified using the same format as value. - ``RSA_KEYSIZE``: How many bits should the RSA modulus (product of the two primes) have for this type of coin. See :doc:`manpages/taler.conf.5` for information on *duration* values (i.e. ``DURATION_WITHDRAW`` and ``DURATION_SPEND`` above, and ``OVERLAP_DURATION`` and ``DURATION`` below). Additionally, there are two global configuration options of note: - ``[taler-exchange-secmod-rsa/OVERLAP_DURATION]``: What is the overlap of the withdrawal timespan for denomination keys? The value given here must be smaller than any of the ``DURATION_WITHDRAW`` values for any of the coins. - ``[taler-exchange-secmod-rsa/LOOKAHEAD_SIGN]``: For how far into the future should denomination keys be pre-generated? This allows the exchange and auditor operators to download, offline-sign, and upload denomination key signatures for denomination keys that will be used in the future by the exchange. .. index:: maintenance .. note:: We recommend setting the ``LOOKAHEAD_SIGN`` value to at least one year and then to perform the offline-signing procedure at least once every 6 months to ensure that there is sufficient time for wallets to learn the new keys and to avoid unavailability in case this critical maintenance procedure is delayed. .. note:: It is crucial that the configuration provided in these sections is identical (!) for the exchange and the crypto helpers. We recommend pointing both users to the same configuration file! .. _Sign-keys: Sign keys --------- There are three global configuration options of note for sign keys: - ``[taler-exchange-secmod-eddsa/DURATION]``: How long are sign keys used to sign messages? After this time interval expires, a fresh sign key will be used (key rotation). We recommend using a ``DURATION`` of a few weeks to a few months for sign keys. - ``[taler-exchange-secmod-eddsa/OVERLAP_DURATION]``: What is the overlap of the timespan for sign keys? We recommend a few minutes or hours. Must be smaller than ``DURATION``. - ``[taler-exchange-secmod-eddsa/LOOKAHEAD_SIGN]``: For how far into the future should sign keys be pre-generated? This allows the exchange and auditor operators to download, offline-sign, and upload sign key signatures for sign keys that will be used in the future by the exchange. .. note:: We recommend setting the ``LOOKAHEAD_SIGN`` value to at least one year and then to perform the offline-signing procedure at least once every 6 months to ensure that there is sufficient time for wallets to learn the new keys and to avoid unavailability in case this critical maintenance procedure is delayed. Terms of Service ---------------- The exchange has an endpoint "/terms" to return the terms of service (in legal language) of the exchange operator. The wallet will show those terms of service to the user when the user is first withdrawing coins. Terms of service are optional for experimental deployments, if none are configured, the exchange will return a simple statement saying that there are no terms of service available. To configure the terms of service response, there are two options in the ``[exchange]`` section: - ``TERMS_ETAG``: The current "Etag" to return for the terms of service. This value must be changed whenever the terms of service are updated. A common value to use would be a version number. Note that if you change the ``TERMS_ETAG``, you MUST also provide the respective files in ``TERMS_DIR`` (see below). - ``TERMS_DIR``: The directory that contains the terms of service. The files in the directory must be readable to the exchange process. The ``TERMS_DIR`` directory structure must follow a particular layout. First, inside of ``TERMS_DIR``, there should be sub-directories using two-letter language codes like "en", "de", or "jp". Each of these directories would then hold translations of the current terms of service into the respective language. Empty directories are permitted in case translations are not available. Then, inside each language directory, files with the name of the value set as the ``TERMS_ETAG`` must be provided. The extension of each of the files should be typical for the respective mime type. The set of supported mime types is currently hard-coded in the exchange, and includes HTML, PDF and TXT files. If other files are present, the exchange may show a warning on startup. Example ^^^^^^^ A sample file structure for a ``TERMS_ETAG`` of "v1" would be: - TERMS_DIR/en/v1.txt - TERMS_DIR/en/v1.html - TERMS_DIR/en/v1.pdf - TERMS_DIR/de/v1.txt - TERMS_DIR/de/v1.html - TERMS_DIR/de/v1.pdf - TERMS_DIR/fr/v1.pdf If the user requests an HTML format with language preferences "fr" followed by "en", the exchange would return ``TERMS_DIR/en/v1.html`` lacking an HTML version in French. .. _Bank-account: Bank account ------------ To configure a bank account in Taler, we need to furnish two pieces of information: - The ``payto://`` URI of the bank account, which uniquely idenfies the account. Examples for such URIs include ``payto://iban/CH9300762011623852957`` for a bank account with an IBAN or ``payto://x-taler-bank/localhost:8080/2`` for the 2nd bank account a the Taler bank demonstrator running at ``localhost`` on port 8080. The first part of the URI following ``payto://`` (“iban” or “x-taler-bank”) is called the wire method. - The ``taler-exchange-wirewatch`` and ``taler-exchange-transfer`` tools needs to be provided resources for authentication to the respective banking service. The format in which the authentication information is currently a username and password for HTTP basic authentication. You can configure multiple accounts for an exchange by creating sections starting with “exchange-account-” for the section name. You can ENABLE for each account whether it should be used, and for what (incoming or outgoing wire transfers): .. code-block:: ini [exchange-account-1] # With x-taler-bank (say for PyBank) PAYTO_URI = "payto://x-taler-bank/bank.demo.taler.net/Exchange" # Example using IBAN (for use with LibEuFin) # PAYTO_URI = "payto://iban/CH9300762011623852957" # URL for talking to the bank wire the wire API. WIRE_GATEWAY_URL = https://bank.demo.taler.net/taler-wire-gateway/Exchange # Use for exchange-aggregator (outgoing transfers) ENABLE_DEBIT = YES # Use for exchange-wirewatch (and listed in /wire) ENABLE_CREDIT = YES # Authentication options for exchange bank account go here. # (Next sections have examples of authentication mechanisms) WIRE_GATEWAY_AUTH_METHOD = basic USERNAME = exchange PASSWORD = super-secure The command line tool ``taler-exchange-offline`` must be used to sign the ``payto://`` URI in a way suitable to convince wallets that this is the correct address to wire funds to. For example, the utility may be invoked as follows to enable a wire account: .. code-block:: console $ taler-exchange-offline enable-account payto://iban/CH9300762011623852957 The resulting JSON output must be uploaded to the exchange using ``taler-exchange-offline upload``. For details, see :doc:`manpages/taler-exchange-offline.1`. .. _Wire-fee-structure: Wire fee structure ^^^^^^^^^^^^^^^^^^ .. index:: wire fee .. index:: fee For each wire method (“sepa” or “x-taler-wire”) the exchange must know about applicable wire fees. This is also done using the ``taler-exchange-offline`` tool: .. code-block:: console $ taler-exchange-offline wire-fee iban 2040 EUR:0.05 EUR:0.10 The above sets the wire fees for wire transfers involving ``iban`` accounts (in Euros) in the year 2040 to 5 cents (wire fee) and 10 cents (closing fee). The tool only supports setting fees that applies for the entire calendar year. We recommend provisioning an exchange with wire fees at least for the next two years. Note that once the fees have been set for a year, they cannot be changed (basically, by signing the fees the exchange makes a legally binding offer to the customers). .. index:: maintenance .. note:: Provisioning future wire fees, like provisioning future denomination and signing keys, are key regular maintenance procedures for every exchange operator. We recommend setting automated reminders for this maintenance activity! .. _Auditor-configuration: Auditor configuration --------------------- The exchange must be informed about any auditor that is expected to provision it with auditor signatures. This is also done using the ``taler-exchange-offline`` tool on the offline system. First, the auditor must be configured and provide the exchange operator with its public key and the URL of it's REST API. The exchange operator also needs a human-readable name that may be shown to users to identify the auditor. Given this information, the exchange operator can enable the auditor: .. code-block:: console $ taler-exchange-offline enable-auditor $PUB_KEY $REST_URL "$AUDITOR_NAME" > auditor.json As before, the *auditor.json* file must then be copied from the offline system to a system connected to the exchange and there ``uploaded`` to the exchange. .. _Deployment: Deployment ========== This chapter describes how to deploy the exchange once it has been configured. .. _Launch: Launching an exchange --------------------- A running exchange requires starting the following processes: - ``taler-exchange-secmod-rsa`` (as special user, sharing group with the HTTPD) - ``taler-exchange-secmod-eddsa`` (as special user, sharing group with the HTTPD) - ``taler-exchange-httpd`` (needs database access) - ``taler-exchange-aggregator`` (only needs database access) - ``taler-exchange-closer`` (only needs database access) - ``taler-exchange-wirewatch`` (needs bank account read credentials and database access) - ``taler-exchange-transfer`` (needs credentials to initiate outgoing wire transfers and database access) The crypto helpers must be started before the ``taler-exchange-httpd`` and they should use the same configuration file. For the most secure deployment, we recommend using separate users for each of these processes to minimize information disclosures should any of them be compromised. The helpers do not need access to the Postgres database (and thus also should not have it). The processes that require access to the bank account need to have a configuration file with the respective credentials in it. We recommend using a separate configuration at least for ``taler-exchange-transfer`` which is the *only* process that needs to know the credentials to execute outgoing wire transfers. All of these processes should also be started via a hypervisor like ``systemd`` or ``gnunet-arm`` that automatically re-starts them should they have terminated unexpectedly. If the bank is down (say for maintenance), it is *possible* to halt the ``taler-exchange-wirewatch`` and/or ``taler-exchange-transfer`` processes (to avoid them making requests to the bank API that can only fail) without impacting other operations of the exchange. Naturally, incoming wire transfers will only be observed once ``taler-exchange-wirewatch`` is resumed, and merchants may complain if the disabled ``taler-exchange-transfer`` process causes payment deadlines to be missed. .. note:: The ``taler-exchange-httpd`` does not ship with HTTPS enabled by default. In production, it should be run behind an HTTPS reverse proxy that performs TLS termination on the same system. Thus, it would typically be configured to listen on a UNIX domain socket. The ``/management`` and ``/auditors`` APIs do technically not have to be exposed on the Internet (only to the administrators running ``taler-exchange-offline``) and should be blocked by the reverse proxy for requests originating from outside of the bank. (However, this is not a strong security assumption: in principle having these endpoints available should do no harm. However, it increases the attack surface.) .. _Keys-generation: Keys generation --------------- Once the configuration is properly set up, all the keys can be signed using the offline key on the offline system by the tool ``taler-exchange-offline``. To do this, one must first start the crypto helpers and the ``taler-exchange-httpd`` process (the tools for wire transfers may also be started, but do not have to run yet). Next, the *future* key material should be downloaded using: .. code-block:: console $ taler-exchange-offline download > future-keys.json Afterwards, *future-keys.json* contains data about denomination and online signing keys that the exchange operator needs to sign with the offline tool. The file should be copied to the offline system. There, the operator should run: .. code-block:: console $ taler-exchange-offline show < future-keys.json and verify that the output contains the fee structure and key lifetimes they expect to see. They should also note the public keys being shown and communicate those to the *auditors* over a secure channel. Once they are convinced the file is acceptable, they should run: .. code-block:: console $ taler-exchange-offline sign < future-keys.json > offline-sigs.json The *offline-sigs.json* file must then be copied to an online system that is able to again communicate with the exchange. On that system, run: .. code-block:: console $ taler-exchange-offline upload < offline-sigs.json to provision the signatures to the exchange. At this point, the exchange will be able to use those keys, but wallets and merchants may not yet trust them! Thus, the next step is for the auditor to affirm that they are auditing this exchange. Details about this are described in :doc:`taler-auditor-manual`. The simplistic (without using offline keys for the auditor) way to do this would be: .. code-block:: console $ taler-auditor-offline download sign upload For more information, see :doc:`manpages/taler-auditor-offline.1`. Private key storage ------------------- Keeping the private keys the helpers create secret is paramount. If the private keys are lost, it is easy to provision fresh keys (with the help of the auditor). Thus, we recommend that the private keys of the crypto helpers are *not* backed up: in the rare event of a disk failure, they can be regenerated. However, we do recommend using RAID (1+1 or 1+1+1) for all disks of the system. .. _Database-upgrades: Database upgrades ----------------- Currently, there is no way to upgrade the database between Taler versions. The exchange database can be re-initialized using: .. code-block:: console $ taler-exchange-dbinit -r However, running this command will result in all data in the database being lost, which may result in significant financial liabilities as the exchange can then not detect double-spending. Hence this operation must not be performed in a production system. .. _Revocations: Revocations ^^^^^^^^^^^ When an exchange goes out of business or detects that the private key of a denomination key pair has been compromised, it may revoke some or all of its denomination keys. At this point, the hashes of the revoked keys must be returned as part of the ``/keys`` response under “recoup”. Wallets detect this, and then return unspent coins of the respective denomination key using the ``/recoup`` API. To revoke a denomination key, you need to know the hash of the denomination public key, ``$HDP``. The ``$HDP`` value is usually included in the security report that is generated when a compromise is detected). Given this value, the key revocation can be approved on the offline system: .. code-block:: console $ taler-exchange-offline revoke-denominatin $HDP > revocation.json The resulting *revocation.json* must be copied to a system connected to the exchange and uploaded to the exchange using the ``upload`` subcommand of ``taler-exchange-offline``. .. note:: Denomination key revocations should only happen under highly unusual (“emergency”) conditions and not in normal operation. Testing a deployment ==================== We recommend testing whether an exchange deployment is functional by using the Taler wallet command line interface. The tool can be used to withdraw and deposit electronic cash via the exchange without having to deploy and operate a separate merchant backend and storefront. For more information, see :doc:`taler-wallet-cli-manual`. .. _Diagnostics: Diagnostics =========== This chapter includes various sections on specific topics that might be helpful to understand how the exchange operates. The information may also be helpful for diagnostics. .. _Internal-audit: Internal audits --------------- While an exchange should use an external auditor to attest to regulators that it is operating correctly, an exchange operator can also use the auditor's logic to perform internal checks. For this, an exchange operator can generally follow the auditor guide. However, instead of using ``taler-auditor-sync``, an internal audit can and likely should be performed either directly against the production exchange database or against a synchronous copy created using standard database replication techniques. After all, the exchange operator runs this for diagnostics and can generally trust its own database to maintain the database invariants. Running the auditor against a the original the production database (without using ``taler-auditor-sync``) enables the auditing logic to perform a few additional checks that can detect inconsistencies. These checks are enabled by passing the **-i** option to the ``taler-auditor`` command. As always, the resulting report should be read carefully to see if there are any problems with the setup. Reports are generally created incrementally, with ``taler-auditor`` reporting only incidents and balance changes that were not covered in previous reports. While it is possible to reset the auditor database and to restart the audit from the very beginning, this is generally not recommended as this may be too expensive. .. _Database-Scheme: Database Scheme --------------- The exchange database must be initialized using ``taler-exchange-dbinit``. This tool creates the tables required by the Taler exchange to operate. The tool also allows you to reset the Taler exchange database, which is useful for test cases but should never be used in production. Finally, ``taler-exchange-dbinit`` has a function to garbage collect a database, allowing administrators to purge records that are no longer required. The database scheme used by the exchange looks as follows: .. image:: exchange-db.png .. _ExchangeBenchmarking: Benchmarking ============ This chapter describes how to run the Taler exchange benchmark. The benchmark can be used to measure the performance of the exchange by running a (possibly large) number of simulated clients against one Taler deployment with a bank, exchange and auditor. For the bank, both a "fakebank" (``-f``) and a "Pythonbank" deployment are currently supported. The ``taler-exchange-benchmark`` program can launch all required services and clients, or only launch the parallel clients (``-m``), for example for distributed testing over a network. For each *parallel* (``-p``) client, a number of *reserves* (``-r``) is first established by **transferring** money from a "user" account (42) to the Exchange's account with the respective reserve public key as wire subject. Next, the client will **withdraw** a *number of coins* (``-n``) from the reserve and **deposit** them. Additionally, a *fraction* (``-R``) of the dirty coins will then be subject to **refreshing**. For some deposits, the auditor will receive **deposit confirmations**. Operations that are not covered today include closing reserves, refunds and recoups. The existing ``benchmark.conf`` file in ``src/benchmark/`` can be used as a starting point for a configuration to run the benchmark. The existing configuration file only requires that the ``talercheck`` database already exists and will launch all required services locally as needed. You can run a first simple benchmark using: .. note:: FIXME-TTN/CG: these instructions are incomplete and untested for the current iteration of the code... .. code-block:: console $ createdb talercheck # if it does not yet exist $ taler-exchange-dbinit -c benchmark.conf $ taler-exchange-httpd -c benchmark.conf & $ HTTPD_PID=$! $ taler-exchange-offline -c benchmark.conf \ download sign \ enable-account FIXME-DETAILS-MISING-HERE \ wire-fee FIXME-DETAILS-MISING-HERE \ upload $ kill -TERM $HTTPD_PID $ taler-exchange-benchmark -c benchmark.conf -p 4 -r 1 -n 10 This will run 4 parallel clients withdrawing 10 coins from 1 reserve and then depositing those coins. The default refresh probability is 10 percent. Note that the tiny run should only take a few seconds, most of it will be spent in the setup of the original key material. For meaningful runs, all three values should likely be increased. The output of ``taler-exchange-benchmark`` will include for each parallel client the total time spent in each of the major operations, possible repetitions (i.e. if the operation failed the first time), total execution time (operating system and user space) and other details. Naturally, additional instrumentation (including using features of the Postgres database itself) may help discover performance issues.