We are considerung to build an Windows application that is split in 2 parts:
One part running as a Windows service and the other part as Add-Ins.
There could be different kinds of Add-Ins:
For Microsoft Office, for Microsoft Management Console (MMC) and for the PowerShell.
The service as well as the Add-Ins are digitally signed with a companies certificate and are all running on the same machine.
The service runs in a different user account than the Add-Ins.
The Add-Ins may run in various interactive user accounts.
The Add-Ins need to communicate with the Windows service to exchange a secret that is known to the service only, but is needed at the Add-Ins to get access to some sensitive data.
Therefor the Add-In would connect to the service (via e.g. named pipe) and requests that secret on demand.
But we need to avoid that another application/process does the same and gets the secret.
Only those Add-Ins that belong to our application (that are digitally signed with our certificate) may get the secret. In other words, the Add-Ins need some way to authenticate themself to the service.
So my question is:
How can the Add-Ins authenticate themself to the service while requesting the secret? Is it possible to use the digital signature (or someting else that is unique to them and to the service) for this?
It might get more difficult when considering, that the Add-Ins are hosted by processes that might be signed with different certificates (e.g. Word.exe, mmc.exe, …).
We are implementing on the .NET Framework.
Thanks for any kind of help.
Go to Source
Being not a cryptography expert, I am having some basic questions on how to manage keys wrt. sodium-plus. Let me briefly explain the context: the use case involves sending data from a web frontend to a backend, but the backend should not be able to read it (deliberate design choice due to privacy concerns). The data in question needs to be usable from different client machines (the same frontend used at different times on differnet machines). It should be en- and decrypted using a secret that is under the control of the user and not stored by the application. There is no second user involved that should be able to decrypt the data, so I see this as a scenario for using a shared-key encyption approach.
I am looking into using sodium-plus.js for this and in particular to use
crypto_secretbox, but am actually not clear on how to manage the key part in the scenario — ultimately, the user needs to have a way to access the same data on a different machine. Looking through the API documentation, I see two options:
- Generate a random key, convert it to a hex string, present the hex presentation to the user and leave it up to the user how she stores it. Then the user could use this hex presentation on the next client machine to decrypt her data.
Unfortunately, I seem to be unable to re-create a cryptographic key from the hex presentation (
hex2bin returns a (Promise for a) string). Is this even feasible? Also, I’m not at all convinced that this approach is not entirely defeating the idea of generating a random key in the first place?
- Derive a key from a password via
crypto_pwhash that the user has to specify. However, this requires also a salt, so I’m back in a similar unclear situation on how to handle it: if the user would give the same password on a different machine (on which to decrypt the data) I also have to use the same salt to generate the same cryptographic key. How do people handle this?
If I could easily have read up on all of this, I would appreciate pointers, as my search-fu seems to fail me.
Go to Source