I. Security of report messages
Report messages submitted outside the data submission portal by email or web service need to be secured.
Report messages are secured through encryption or digital signatures.
Security for report messages uses apps that support public key algorithms that meet OpenPGP standards (http://www.ietf.org/rfc/rfc4880.txt) or DigiDoc such as PGP, GnuPG and DigiDoc 4.
If report messages are sent using a public channel such as the internet, they must be encrypted and digitally signed.
If report messages are sent using a secure channel such as HTTPS, they need only be digitally signed.
Security with OpenPGP
When using OpenPGP, the following requirements must be met:
- The encryption and signature keys must be RSA V4.
- The key must be a minimum of 2048 bits long.
- The encryption algorithm can be AES or CAST5. The use of the 3DES encryption algorithm is permitted but is not recommended. The use of IDEA is not permitted.
- The hash function should be SHA256. The use of the SHA1 hash function is permitted but is not recommended. The use of MD5 is not permitted.
The separate public keys for the data submission portal for Eesti Pank and Finantsinspektsioon can be found at https://aruandlus.eestipank.ee/reports/
Security with DigiDoc
II. Key management
Key management for OpenPGP
The reporting entity must take responsibility for and organise key management in the data submission portal and must do so in line with the following requirements:
- Keys are usually created within the data submission portal.
- If exceptionally a key is created outside the data submission portal, it must meet the following requirements:
- the user identifier of a key pair must include the code of the reporting entity, the word “aruandlus”, the name of the authorised employee and the final validity date of the key pair;
- key pairs must be changed at least once every two years, and so the maximum validity of keys being created must be set at two years;
- used key pairs must be retained so that changed data may still be accessible;
- key pairs that have become unserviceable must be withdrawn and deactivated.
Key management if the authorised representative of the reporting entity is not able to manage the keys in the data submission portal:
- The reporting entity must appoint a person responsible for organising data exchange, who must ensure the creation of keys for the reporting entity, including the replacement of unserviceable key pairs; their use by approved employees of the reporting entity; and the accessibility of changed data.
- To initiate data exchange, the person responsible at the reporting entity must submit a signed public key, preferably digitally signed, and a key exchange certificate; the key exchange certificate must state the name and key identifiers of the reporting entity, and the authorised employees who will be submitting reports; the key exchange certificate must be signed by a person at the reporting entity with right of signature.
- Only authorised employees may disclose the password phrase protecting the private key of the key pair of the reporting entity.
- When keys are changed the reporting entity and the addressee of reporting exchange new digitally signed public keys.
- In exceptional circumstances where a secret key has become unusable, for example if it has been disclosed or corrupted, the addressee of reporting or reporting entity must be informed of this immediately and a new key pair created and taken into use.
Key management for DigiDoc
When using DigiDoc, the reporting entity is responsible for organising the whole of key management within the data submission portal, including acquiring ID cards, replacing unserviceable ID cards, adding users, or terminating the authority of users.
The key pair must have a unique identifier that should contain the reporting entity’s name if it uses the reporting entity’s ID card. Personal ID cards used with Digi-ID have a unique personal code as identifier.
Key management within the data submission portal is done by users at the reporting entity with the role of primary user and preferred user.