I am trying to prototype a X509 certificates based group enrollment, and not for only one device (as dice_device_enrollment by default would provide), but for several, and, from what I learned, I will need to implement my own custom HSM library. While most of the latter seems straightforward, I have a difficulty with setting deviceID. The document says the following:
custom_hsm_get_common_name
char* custom_hsm_get_common_name(HSM_CLIENT_HANDLE handle);
Retrieves the common name from the x509 certificate.
Passed to the Device Provisioning Service as a registration Id.
My difficulty is - if "registration ID" is deviceID, and an X509 certificate has only one common name, how am I supposed to provision multiple devices in a group? Or, is there any other way that deviceID is set? Currently by analysing the code of hsm_client_riot.c I can't see that.
Just to close this one. Since July 2019 a new version of Azure IoT SDK for Python has been released, which handles device provision better than the old SDK (which I was referring to). The question is obsolete now. Use the new SDK.
Related
I've been writing client certificate code for iOS using many of the resources here: iOS Client Certificates and Mobile Device Management and I've broken out the process to these steps:
Get the Cert via email or AppConfig
Store the Cert (securely)
Extract Identity and Trust from the Cert.
Intercept failed web requests, create NSURLConnection to manually handle auth responses as per Eskimo's advice.
Turn Identity and Trust into the auth response challenge.
My problem is step 2. SecPKCS12Import function appears to automatically add Identity to the keychain as well as return all Identities and Trusts from the certificates, thus eliminating the need for the convenience function often given ExtractIdentityAndTrust().
But on my 2nd run, I will need the Identity and Trust, not just Identity. My current plan is to store the entire cert raw using SecItemAdd, test for duplicates and use it, but I feel like I should be able to just use SecPKCS12Import then later grab it without also using SecItemAdd.
The documentation that is most confusing is SecPKCS12Import, and I would like a clearer understanding of what it does vs secItemAdd, and if secItemCopyMatching() is the same in the end just to grab the certificate. Is Trust not needed or am I just being literal and it's stored with the identity?
The general save, use, store, grab is working, but I'm using NSData and would prefer to store it correctly
I eventually became more familiar with the KeyChain and Identity vs Trust and learned this:
The Trust is a Cert stored in a place that determines who your custom Certificate Authorities are. It only needs to be tested once, which is why it isn't stored.
Storing the Identity is also a certificate, but needed for later. The keychain considers Certificates/Identities to be a Special/Unique thing so it is stored as its own thing, which is why all the keychain code looks different than just securing a password.
Basically, storing the Trust is unnecessary for future reference, but should be checked for good practice. I personally think an expiration might be handy
I try to send a push notification using ionic cloud, but Google now requires a restriction key . I don't know how to get key restriction. Please help me.
Update: There is now a visible note in the GCM docs saying:
Starting from Sept. 2016 new server key can only be created in the Firebase Console using the Cloud Messaging tab of the Settings panel. Existing projects that need to create a new server key can be imported in the Firebase console without affecting their existing configuration.
There have been recent changes with regards to the Google Developers Console interface when generating an API Key. Before there used to be a part where you have to select what type it is (Server, Android, iOS, Browser keys). But now, it automatically creates then you can simply select the type of restriction you want, depending on where you'll use the key.
I haven't tried using Ionic before, but I think it's pretty much the same where you'll use the API key (in this case, the Server Key). Simply set the correct server IP Address in the IP address whitelist and try again.
Do keep in mind that adding restrictions are highly encouraged for your security against unauthorized use and quota theft (seen as a warning for API keys with no restrictions).
See my answer here for more details.
I have associate my Windows Store app with the Windows store and I got a "Appname_StoreKey.pfx" key file, and I deleted my temporary key. If I create my app package using this key will my app expires after a month?
Temporary key expires on a month but this StoreKey says it will expire after a year. Please explain any cons of this procedure.
Due to company requirement I can't submit the app to the store.
The test certificates will expire one year (not month) after creating them. Technically you can use these to publish your app, but this is not recommended.
The same is true if you get a [appname]_StoreKey.pfx after associating your app with the store.
You can view the expiration date in VS, see screenshot.
This cert is taken to sign your code. The app package signature ensures that the package and contents haven't been modified after they were signed.
When you're not deploying using the store the disadvantage is that during deplyoment, the certificate is not trusted. This is in both cases no matter if you take the testcert or the storekey.pfx.
Your users are required to first install the certificate. This is something they might not be able to do (missing rights) or don't dare to do (because they're scared).
When you take a closer look, you will find that the issuer name of testcert might look good, and probably looks very strange (long guid) for a StoreKey.pfx . So users who are asked to install the cert might be scared for a reason.
The best way is to use your own certificate that you created that won't expire too early and that is installed by your IT device management Infrastructure (if you're building a company app for example). This will lead to a struggle-free installation for users.
Using a test certificate is possible technically but not a very "clean solution".
Also check out this post
https://msdn.microsoft.com/en-us/library/windows/apps/br230260(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/windows/apps/jj835832.aspx
My company develops an ERP for hospitals and because of some legislation changes throughout this weekend I've been reading a lot on digital signature because I need to solve the following scenario:
Each doctor will receive from the ministry of health a certificate (so there's no escape from it... government said so...) and all of his reports sent/stored in digital format must be signed with this certificate.
The certificates will be valid for one year. Each year upon renewing of the medical license, the certificate will be renewed.
Our main concern here is guaranteeing the source of the document (the sender is who he claims to be) but we must also make "impossible" (or at least infeasible) to change the content of the document (or at least that if it changes, we have to be able to tell that a modification occurred) and to "extracted and replicated" the signature...
My question is: how do I deal with this whole thing? What should I do?
PS: In your answer pls consider that:
The documents will persist far beyond the certificate lifetime.
The certificate might have been revoked. Documents signed before the revoke must still be valid
How a 3rd party would verify the integrity of the information (document + certification)
Is there not a security principle which states that information signed with a expired certificate is invalid or something?
I'm really new to this area and I might be asking the wrong question...
In brief, the document must be signed using CAdES, PAdES or XAdES (depending on data format) standard, where timestamping is applied and other measures are taken. These standards were designed specifically for tasks similar to yours so they address your concerns. I recommend that you read some articles about those formats. Unfortunately I don't have a link to share with you right now, but you can find a lot based on those abbreviations.
CAdES is based on PKCS#7/CMS (certificate-based signing of generic data with wrapping signatures) .
PAdES is an extension of PDF signing and is used specifically for PDF documents.
XAdES is similar to CAdES and can be used to sign XML documents and (more rarely) binary data.
[Disclosure: I work for CoSign by ARX.]
Your situation is common. You're raising a number of questions. My answers:
all of his reports sent/stored in digital format must be signed with this certificate.
You can digitally sign anything (any bundle of bits). The real issue is how can the recipient or auditor easily verify that the document:
was not modified since it was signed (integrity)
was signed by the right person (identity)
was signed with the right intent (signer's statement)
Machine readable data, eg form data, intermediate data, etc.
Signing: For info that is designed to be later machine-read (eg a form submission), store the info in XML and sign it using the XML Signing Standard: XAdES The CoSign Signature API (SAPI) directly supports signing XML docs.
Verifying There are many on-line XML digital signature verification services, Google for them. The SAPI api also supports verifying XML docs.
Human readable documents
Signing: For a "final" document that will be read by humans (but is stored digitally, can be included in searches, etc), PDF documents are the way to go. The PDF format supports digital signatures very well. There are many ways to add digital signatures to PDF documents. For developers, the CoSign Signature Web Agent is a web service (HTTPS + XML parameter document) that handles all the UI issues of signing.
Verifying: The most common way to verify the digital signatures of a pdf is to use the free Adobe Reader. (Not the expensive Adobe Acrobat.) Adobe Reader knows how to check the validity of the digital signatures and then tells the reader/signer/auditor that the signature is valid, the document was not changed since signed, etc.
Your other questions:
The documents will persist far beyond the certificate lifetime.
Yes, that is fine. Just like a "wet signature," once you've validly digitally signed a document, that document remains signed by you. -- Even if your signing certificate later expires. As part of the verification process, the date of signing is compared with the valid dates on the certificate.
The certificate might have been revoked. Documents signed before the revoke must still be valid
Yes, that is how standard digital signatures work. Even if a certificate is revoked, documents signed while the certificate was valid will remain signed. Because date/timestamps play such an important part of the validation process, there are 3rd party timestamping services available. But they are not used for most digital signatures. Instead, create explicit management procedures to make sure that the time server is properly setup with NTP to a good source and that the system is regularly checked and verified.
CoSign signs using a tamper-proof hw device. Its clock is synched using NTP.
How a 3rd party would verify the integrity of the information (document + certification)
As I discuss above, the whole verification question is important. That's why I recommend using XML or PDF as your document types. You could, for example, digitally sign your own system's internal data structure used to represent information. In this case the digital signature would be carried in a separate data structure. This is the "external signature" scenario. It all works fine, except that an auditor would need to either build his own sw to validate or trust that your sw is doing the validation properly. A better choice is to use a format that directly supports digital signatures and which can be easily verified.
Is there not a security principle which states that information signed with a expired certificate is invalid or something?
A proper digital signature system won't allow an expired certificate to be used to sign anything. Once something is signed, using a certificate that was valid at time of signing, it stays signed unless the document is subsequently changed.
I'm really new to this area and I might be asking the wrong question...
Other questions to ask: how do you add the signer's graphical signature to the document (XML or PDF)--people expect to see it. And how do you manage/administer the certificates? Server based signing is a good solution for this. Remember that certificates should not be stored in sw for any production systems. Instead, a Secure Signature Creation Device (something hw based) must be used.
You will also need to read the Baseline Profiles where there is a profile for long-term signatures.
There is a profile for each of the formats already mentioned by Eugene.
For example, if your document is PDF, you may use PAdES signatures and the LTA-Level specified in "PAdES Baseline Profile" document.
All of these documents are ETSI standards you can search for at: http://pda.etsi.org/pda/queryform.asp
I have to find whether Smart Card has a given certificate in it. For that I am first acquiring the HCRYPTPROV (handle to the CSP) using CryptAcquireContext and then using it to Open the system store (OpenSystemStore) and then enumerating the certificates.
It works perfectly on Windows XP. On Windows 7 it gives issue due to stale/old certs stored in store.
Windows stores/copies the certificates in its store from Smart Card. That means if I have two certificates Cert1 and Cert2 on Smart Card and I have used smart card to logon into windows. then Windows stores these certs in its stores, we can see that by going to IE->Internet Options->Contents->Certificates. Then if I remove the Cert2 from the Smart Card, then also Cert2 is shown in Windows Store and this thing is breaking my code.
So I need to enumerate the certs which are available only on the Smart Card not in the Windows store.
Assuming the HCRYPTPROV you acquire is for the smart card, use CryptGetProvParam with the PP_USER_CERTSTORE parameter:
Obtains the user certificate store for the smart card. This certificate store contains all of the user certificates that are stored on the smart card.
e.g.
HCERTSTORE hCertStore = NULL;
DWORD size = sizeof(hCertStore);
CryptGetProvParam(hProv, PP_USER_CERTSTORE, (PBYTE)&hCertStore, &size, 0);
You can then enumerate the smart card's certificates from the HCERTSTORE as with the system store.
The MSDN page states "Windows XP: This parameter is not supported." but it works fine on XP with the latest Service Pack.
The CNG equivalent is NCryptGetProperty with the NCRYPT_USER_CERTSTORE_PROPERTY parameter.