Generating encrypted logs in a untrusted machine

Question

Hi guys,
I would like to get some ideas from your guys on how to solve a problem.
Basically, we have an application that is installed in a unstrusted computer (i.e. the person whom uses this computer cannot be trusted).
Unfortunately, the guys whom install the application is untrusted as well.
Basically this application allows the user to perform some operations in the field (generate some log of those operations) and when the user returns
to the headquarter those logs are read, so we can check if "field user" did any malicious action. The problem is that this log MUST be encrypted, otherwise
he can edit the log file and cheat the system.
Do your guys have any idea on how to solve that?
PS: I was thinking on give a public key that should be used during the product installation (by using keytool) and use a private key on the server to read the logs, however I don't know if that is the best solution.
Thanks and Regards

Answer 1

Those cmdlets use DPAPI (
http://msdn.microsoft.com/en-us/library/ms995355.aspx .)  DPAPI does generate new Master Keys from time to time, but they're all stored in the user's profile, and you should not lose the ability to decrypt old data.  Few questions:
Is this script running as a domain account, or as a local user?
Does anyone mess with the account's user profile, deleting all or parts of it and allowing them to be recreated?
Your DPAPI master keys are stored in <Profile Dir>\AppData\Roaming\Microsoft\Protect\<Account SID>\ .  They're marked as Hidden and System, so you'll need to make sure you're viewing those files to be able to see them.
The master key files in that directory are encrypted using a hash of the user's password; if anyone resets the password, you lose access to those keys (unless you're either in Active Directory, which has a backup mechanism in place on the domain controllers,
or you have made a Password Recovery Disk for a local account.)  You mentioned that the account's password hasn't changed, so that's probably not an issue here, but I figured I'd mention it so you know how DPAPI works.
If the account's password has not changed at all, my best guess is that someone has managed to delete the old master key(s) from the user profile, one of which was used to encrypt the SecureString originally.