Methods to keep an autonomous log with high integrity

Question

I'm writing a .NET desktop application that is used to send orders to a server via a REST API. To avoid leaking of our authentication token I have made it so that, when used for the first time, the user has to submit the authentication token and a password to encrypt it with.

The encryption algorithm is AES-256-CBC and the scheme is as follows: the password is hashed before it's used by the algorithm, the salt used for hashing is the computer GUID so just copying the program files will not suffice, and the IV is randomly generated and concatenated with the cipher. When the user opens the program thereafter, he or she is asked for a password, decryption is started, and when the authentication token does not match the required mask it will return an error. So far so good I'd say.

However, my supervisor is not yet content with the level of security: he wants the program to log all orders that have been sent to the server in case of administrative anomalies by the third party that hosts the server, just so that we have a reference with a reasonable level of credibility (though I suppose you could just call it 'proof' in case their administration fails). The 'credibility' part is where any straightforward implementation of a logfile goes right out the window, it wouldn't provide:

• Integrity: No person (including the user) is allowed to modify the logfile with content that does not reflect actual usage of the program. The log can only be appended, only when the program's main function is used, and only by the program itself.
• Confidentiality: The contents of the log can only be summoned by the user of the program (the password prompt will aid in identification of the user).

I've tried to come up with a cryptographic scheme (digital signing) encrypting every record that is appended to the log and encrypt the public key with the user's password, but this doesn't solve half the problem: the private key would have to be stored by the program anyhow, so strictly speaking it means the user has access to it and have the ability to modify the log.

Is there a method or scheme that meets these requirements?

Answer 1

You are correct in that it is an intractable problem very similar to the why DRM can never be provably secure. You can make it very difficult for a user to forge the log but ultimately the application will need to have the key needed to digitally sign log messages. If the key exists on the client computer it can be removed from the client computer.

The old maxim of "there is no information security without physical security" is in play.

So a lot comes down to what level of integrity is required. How likely are users to try and forge the log? What is their potential gain? I would be honest with your boss on how perfect security can not be achieved.

Technical details of the logging

It isn't exactly clear so I just thought I would clarify. The application should contain a private key for signing. You may want to make this client specific to compartmentalize the risk. There are ways to make the extraction of this private key more difficult but it is important to be open and transparent then you can't make it impossible. The public key is known to both user and you for authenticating the log. Application signs the log message and then encrypts with a key derived from user's password.

Depending on the level of security and cost of the software someone on the team might suggest using a hardware dongle or usb token for storing the private key. Just keep in mind that while this makes key strong more secure if the attacker can feed a false message to the dongle for signing then the attacker can alter the log without gaining direct access to the key.

Technical details of REST API

You may wish to reconsider allowing the client to determine if the token is valid in order to prevent offline attacks. If the token is stored encrypted on the client machine an attacker with access to the filesystem could extract the encrypted token and brute force it offline until he discovers the valid token.

On the other hand if the authentication token can only be validated by the server then the only way to brute force the user's password is to make a request to the server. This allows you to limit the throughput of such brute force attacks, locks accounts, and ban ip if necessary. It becomes more difficult to gain unauthorized access to a token. There are two ways to achieve this. The simpler method if you can make tokens arbitrary would be to make the token simply a derivation (PBKDF2) of the user's password.

If token must be independent of the user's password or is predefined then you could encrypt and store it on the client just do so in such a way that for any password a decrypted token is returned and valid vs invalid tokens can not be distinguished without communicating with the server.

If you go this route then to avoid information leakage the logs would need to be encrypted not by a key derived directly from user's password but by a key provided by the server upon request (with proper authentication token). Otherwise an attacker can simply brute force the logs offline and use that as a canary to identify the correct password and thus token.

Answer 2

I would use an externally provided service (Splunk on Cloud, Papertrail - there are others but i have used these ones) to ensure reasonable integrity. Or use your own, separated from the service (based on a commercial solution or, for instance, ELK)

The confidentiality part is more tricky. For the Splunk case, if you have a pre-defined list of users, you could create views with a per user content and give read rights to appropriate users. This is hardly scaleable, though.