I'm trying to learn a little about Windows application development, and I have yet to wrap my head around certificate handling.
Is encryption and decryption handled by Windows OS functions, or by fetching the private key from the store and performing the cryptographic tasks separately?
An example: assume I have some web page hosted with IIS using SSL certs.
Is e.g. the IIS web server using api calls like the one below, or does IIS ask the OS to encrypt/decrypt using some user selected cert from the store?
https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.x509certificates.rsacertificateextensions.getrsaprivatekey?view=net-5.0
I na given case, IIS acquires private key handle and calls CrypoAPI functions to performs cryptographic operations. Though, IIS doesn't use referenced API, it uses native functions directly.
Windows uses abstraction layer by defining APIs for cryptography and one important part of these APIs is key handle. OS may not have access to raw key material and use key handle to access the key by key owner. Key owners are implemented as Cryptographic Service Provider (CSP) or modern Key Storage Provider (KSP). When necessary, OS calls implemented API and pass key handle to CSP or KSP. Then CSP/KSP implementation is responsible for raw key material access actual cryptographic operations. CSP/KSP implementation is vendor-specific. Windows ships a dozen of software-based CSP/KSP implementations and 3rd party vendors may ship their own implementation, especially when key stored on a hardware (smart card or HSM).
In any way, OS don't care how and where the key is stored, it simply calls defined API, passes key handle and input parameters. CSP/KSP then accesses raw key material, perform requested operation and return result back to caller.
And here is the answer to your question: cryptography operations are handled by CSP/KSP that owns/stores particular key identified by key handle. Whether it is OS or not depends on CSP/KSP implementation. If it is software, then most likely (not necessary, but very often) it is handled by OS. If it is hardware, then it is handled by hardware itself.
I am designing a generic Java library which needs to Sign messages before Sending and Verify messages before accepting. Sign and Verify needs to work with both of the following constraints;
Use raw 32 characters long key with some additional details like key start date, end date, grace period, the algorithm as raw information (do not have a choice, but have to accept it as raw data).
Use a proper PKI certificate containing a public key
For PKI based secret it is straightforward to use JKS/PKCS12 to store information and use it.
The problem I am facing is how do I manage and store raw information? What should be the data structure? So far my options are;
Use JCEKS provided by JRE to store all the raw information in my own made up data structure as secret properties and resolve at runtime to execute my library
Use JKS/PKSC12 and along with X509 Certificate data structure to store all raw information under its Extensions
What I am really looking for is the best practices for these kinds of versatile requirements i.e. manage un-managed secret properties?
I need to use the session key with my geocode requests to limit my billable transactions. The search manager class takes the map as an argument but I see no way to set the session key. Cursory investigation with Charles seems to indicate it doesn't use the session key even after calling getCredentials on its own.
If this can't be done readily it would seem like a glaring oversight.
The Search, AutoSuggest and Direction modules all automatically use session keys when you pass a map in when loading the manager of that module. No need to get the session key yourself. You only really need to manually get the sessions key if you were to directly connect to the REST services which.
Depending on your application needs, directly accessing the REST services may be useful. Here are a couple of examples of when you would want to access the REST services directly:
You only need the raw data.
You want 100% full control over rendering of the results.
You want to access one of the services that are not exposed as a module such as the elevation service.
Are there any examples of using encryption to encrypt the disk-cache used by OkHttp's HttpResponseCache? Naively, I don't think this is a very hard thing to do, but I'd appreciate any advice or experience to avoid security-pitfalls.
Without too many specifics, here's what I'm trying to achieve: a server that accept user's api-keys (typically 40-character random string) for established service X, and makes many API calls on the users behalf. The server won't persist user's api-keys, but a likely use case is that users will periodically call the server, supplying the api-key each time. Established service X uses reasonable rate-limiting, but supports conditional (ETag, If-Modified-Since) requests, so server-side caching by my server makes sense. The information is private though, and the server will be hosted on Heroku or the like, so I'd like to encrypt the files cached by HttpResponseCache so that if the machine is compromised, they don't yield any information.
My plan would be to create a wrapper around HttpResponseCache that accepts a secret key - which would actually be a hash of half of the api-key string. This would be used to AES-encrypt the cached contents and keys used by HttpResponseCache. Does that sound reasonable?
Very difficult to do with the existing cache code. It's a journaled on-disk datastructure that is not designed to support privacy, and privacy is not a feature you can add on top.
One option is to mount an encrypted disk image and put the cache in there. Similar to Mac OS X's FileVault for example. If you can figure out how to do that, you're golden.
Your other option is to implement your own cache, using the existing cache as a guide. Fair warning: the OkResponseCache is subject to change in the next release!
I was thinking of making a small tool. It is not important what the tool will do. The important thing, is that the tool will need to store some sensitive information on the user's HDD. EDIT: The information that will be stored is USER'S information - I'm not trying to protect my own content, that I distribute with the app.
I understand that I need to encrypt this information. But then, where do I safely store the encryption password? It's some sort of an infinite recursion...
So, is there a way, to encrypt information on windows, and have windows securely manage the passwords? When I say windows I mean Windows XP SP2 or later.
I should also note, that users on the same system must not have access to other users information (even when they are both running my application).
I'm looking for both - .NET 2.0 (C#) and native (C/C++) solutions to this problem.
is there a way, to encrypt information on windows, and have windows securely manage the passwords?
CryptProtectData: http://msdn.microsoft.com/en-us/library/windows/desktop/aa380261(v=vs.85).aspx
Using from .NET: http://msdn.microsoft.com/en-us/library/aa302402.aspx
Historically, Protected Storage (available in XP, read-only in vista+): http://msdn.microsoft.com/en-us/library/bb432403%28VS.85%29.aspx
You should consider using DPAPI for this purpose. It will encrypt your data with a special (internal) symmetric key which is on per-user basis. You don't even need to ask for passwords in this case, because different users on the system will have different keys assigned to them.
The downside of it might be that you can't recover the data if the user is deleted/Windows reinstalled (I believe that this is the case, not quite sure though). In that case encrypt the data with a "self-generated" key derived from the password and store the password in registry/file encrypted using DPAPI.
You can use the native encryption facility. Set the encrypt attribute on your folder or file (from the property page, click on the "advanced" button). Then you can set the users that can access the file (by default this only includes the file creator). The big advantage of this solution is that it is totally transparent from the application and the users points of view.
To do it programmatically: using the Win32 API, call EncryptFile() on the directory where you want to store your sensitive per-user data. From now on all newly created files within this dir will be encrypted and only readable by their creator (that would be the current user of your app). Alternatively you can use the FILE_ATTRIBUTE_ENCRYPTED flag on individual files at creation time. You can check encryption info from the explorer on the file's property page, and see that app-created files are correctly encrypted and restricted to their respective users. There is no password to store or use, everything is transparent.
If you want to hide data from all users then you can create a special app-specific user and impersonate it from your app. This, along with ACLs, is the blessed technique on Windows for system services.
You might want to look at Isolated Storage, which is a way of storing settings and other data on a per-application data automatically.
See an example and MSDN.
This is an alternative to storing normal settings in the registry, a better one in a lot of cases... I'm not sure how the data is stored to file however so you'd need to check, you wouldn't want it to be accessible, even encrypted, to other users. From memory only the app. that created the storage can open it - but that needs checking.
Edit:
From memory when I last used this, a good approach is to write a "Setting" class which handles all the settings etc. in your app. This class then has the equivalent of Serialize and DeSerialize methods which allow it to write all its data to an IsolatedStorage file, or load them back again.
The extra advantage of implementing it in this way is you can use attributes to mark up bits of the source and can then use a Property Grid to quickly give you user-edit control of settings (the Property Grid manipulates class properties at runtime using reflection).
I recommend you look at the Enterprise Library Cryptography Application Block. Check this blog post. Windows has a built in Data Protection API for encrypting data, but the Crypto Application Block makes it more straightforward.
Um, what you're trying to achieve is exactly what DRM tried to achieve. Encrypt something then give the user the keys (however obfuscated) and the crypto. They did it with DVDs. They did it with Blu-Ray. They did it with iTunes.
What you are proposing to do will never be secure. Your average lay person will probably not figure it out, but any sufficiently motivated attacker will work it out and discover the keys, the algorithm and decrypt the data.
If all you're doing is encrypting user data then ask the user for their password. If you're trying to protect your internal data from the user running the application you're S.O.L.
Erm hash the password? You don't need to store the real deal anywhere on the machine just a hashed password (possibly salted too). Then when the user enters their password you perform the same operation on that and compare it to the hashed one you've stored on disk.