We are using CEFSharp and have a question about US export regulations for our software. Do CEFSharp have a ECCN (Export Control Classification Number) assigned for this product and a corresponding license type?
If the product does not contain or use any encryption or cryptography functions when running on a (at end user) system the ECCN is not required (see requirements for ECCN https://www.bis.doc.gov/index.php/licensing/commerce-control-list-classification/export-control-classification-number-eccn ).
If CEFSharp creators could give some information about this it would be very helpful.
Related
I have an XF app that I'm trying to provide multiple languages for using resx/AppResources files. However, I have a need to be able to access the English (default language values) at runtime for logging purposes. Basically the app has Activities that the user can complete. Each activity has a title that is translated. When an activity is completed by the user I want to log it too my server so I can see which activities are being used the most. Obviously I'd rather not log the Chinese titles.
What are the best way(s) I can retrieve the default language values regardless of what the App's current language is set to?
Regards,
Sean
On Android:
Locale.Default.GetDisplayLanguage(Locale.Default)
On IOS:
var te = NSLocale.CurrentLocale.LocaleIdentifier;
We just bought a license for the SQLite Encryption Extension. In the documentation it says:
If you deploy the SQLite encryption extension as a DLL or shared
library then you must first activate the library by invoking:
sqlite3_activate_see("7bb07b8d471d642e");
The argument is your product activation key. The activation key is
available as plain-text in the source code so you can clearly see what
it is. The purpose of the activation key is to prevent one of your
customers from extracting the SQLite library and using it separately
from your application. Without knowledge of the activation key, which
only you should know, your users will be unable to access the
encryption features.
Where do I find the product activiation key that I have to use here (we only receivedy user name and password after buying the license)?
I guess I understand that now. We can define our own key as the product activation key and put it both in our source code and in the SQLite source code here (replacing the default/placeholder key):
SQLITE_API void sqlite3_activate_see(const char *zPassPhrase){
encryptionEnabled = strcmp(zPassPhrase, "7bb07b8d471d642e")==0;
}
I am looking for the XSD to use to support a Decoding action in Logic Apps for the X12 830 00200. This was approved by ANSI in 1986 (pre-ASC), but is still widely used by Ford. I understand the same XSD would be used in a BizTalk Server solution. Does anyone have one to share?
I have tried the download item MicrosoftEdiXSDTemplates.zip as part of Microsoft Azure BizTalk Services SDK Setup:
https://www.microsoft.com/en-us/download/details.aspx?id=39087
However that only goes back to 00204, which I tried unsuccessfully adapting.
I would rather not do this as a Flat File Decode, as I want all X12 830 processing in my Logic Apps solution to have a consistent, Agreement-based configuration.
I have sample EDI, drawn from the real-world.
I will be using Ford's specs for the v002001FORD 830O to validate any schema I obtain or create: https://www.gsec.ford.com/GEC/edispecs/830.pdf
** UPDATE **
Thanks all for the help. It ends up that on the MS side, the Kusto log analytics trace of my run-time activity shows explicit duplicate schema references in my Agreement, while my run-time exception from Logic Apps does not clearly indicate a duplicate schema issue is present: 'The message has an unknown document type and did not resolve to any of the existing schemas configured in the agreement.' So, there was nothing wrong with my schema. I just had to tweak my Agreement configuration. I am reporting this to MS and hope the schema validation in the Agreement and/or the exception reporting will be improved.
To me a broader issue is that the X12 schema provided are ASC-issued ones: 02000, 03000, 04000, etc.. The same ones prevented from being shared on Git due to copyright issues. The reason I believe I am running into older, ANSI-issued specs still in used despite their age by Ford, Toyota, etc. is that the same copyright issues tends continued usage by OEMs of these specs despite their age. For that reason, it would be a big help to the community if MS provided the XSDs for the ANSI-issued X12 specs as is done for the ASC-issued ones. For each ASC-issued spec, such as 04000, there are many documents: 830, 856, etc. This multiplies out to scores if not hundreds of handcrafted XSDs one may need to produce (as is our case) to implements broad X12 support in Logic Apps.
The process with outlier EDI Schemas is to find the closest one and modify it to support the version you need.
What do you mean by 'unsuccessfully adapting'? This is not an uncommon thing.
Since the spec is so old, one thing I would very much consider is bumping the interchanges up to a 'current' :) version, even just 00204. I'm not sure the specific value 00200 will work with BizTalk EDI.
You would use a custom Pipeline Component for the incoming and should be able to use the EDI.Override properties on outbound.
Is it possible to "retarget" keys generated via the ncipher JCE API to pkcs11? I know that you can retarget via the generatekey command but I don't see how to do it to an existing JCE key. The first prompt is for the "source application" and the options don't seem to include JCE. Does it support other options beyond the ones listed there or should I be looking at a different way of retargeting?
The ultimate goal here is to export a couple keys (asymmetric and symmetric) that were generated via nCipher's JCE API (yes, I know that an HSM's job is to secure the keys and exporting is usually not a good idea but it is a requirement here). We are able to export keys that were generated via the PKCS11 interface but not ones that were generated via the JCE so our thinking is that if we can retarget it from JCE to PKCS11 we might be able to export these keys as well. If there is another way to do this we are open to that as well.
Lastly, the JCE keys show up as "recovery enabled" when executing the nfkminfo on them. Does that mean that they are exportable or does recovery here mean something else?
Disclaimer: I work for Thales e-Security but do not speak for the company.
Yes you can retarget a jcecsp key to pkcs11. If you have any jcecsp keys in your kmdata/local, /opt/nfast/bin/generatekey will offer jcecsp as a source option. If you have no keys of that ilk, it will quietly omit that option from the source list. However, this retarget process may not do what you think it does. All retargeting does is change the application type and potentially the associated metadata: it doesn't change the fundamental capabilities of the key as those were baked into the protected key blob at generation time and cannot be changed.
The Security World uses nShield key ACLs to limit the key's capabilities (Sign, Verify, Encrypt, Decrypt, Wrap, Be Wrapped, etc.). PKCS#11 pulls its parameters (CKA_SIGN, etc.) directly from the key ACLs, and when generating keys through the API, the ACLs saved in the key blob are derived directly from the parameters in the key template. If you set CKA_SENSITIVE to FALSE, and your Security World allows it, you can generate and save an exportable key. JCE is not that sophisticated: it has no concept of key capabilities at all, so the Provider has to guess at the user's intent with the key and it defaults to a fairly generous set. However, since as you point out the whole idea of HSMs is to protect key bits and not let you have them, Export is not one of the defaults. And what's not baked into the key file when you create it, you don't get by retargeting the key.
One thing you could do if you want to use JCE is to generate the key using a different Provider and then store it in an nCipher.sworld KeyStore using the nCipherKM Provider: this will import the key into the Security World (if your World allows that) and save it as a key_jcecsp_* file. However this has nothing to do with key security so from an HSM perspective it's not recommended. Another thing you could do is to drop down to the native nCore API, generate the key with the ACL entries you require, and then polymorph it to a JCE Key Object and save it in the HSM-backed KeyStore. You can shoot yourself in the foot as many times as you want with the ACLs on the key you create. The polymorphing is very poorly documented: ask Thales Support and they can guide you.
Finally, the Recovery capability means that in addition to the Working Key blob which may be protected by an Operator Card Set, the key file has a Recovery Blob. This is in case that Operator Card Set is lost: the Recovery Blob can be opened up by the Administrator Card Set of the Security World using the rocs utility (Replace Operator Card Set), which will write a new key file under a new OCS. No, this does not mean the key is exportable. It just means that you are protected against losing the OCS. Of course losing the ACS is a non-starter as that is your Root of Trust.
What is the difference between Intel TXT and TPM? What more Intel TXT has to offer as compared to TPM?
Basically, I wanted to know how TXT works? Any easy to follow literature for beginners will be highly appreciated!
Scolytus is right but let me explain a bit more.
As he said, a TPM is a dependency of TXT but not the other way around. The TPM is where TXT will store the measurements - hash of components - of the platform. If TXT is not supported by a platform but a TPM is still present you still have all those features:
Integrity measurement – securely measure the platform's components (hashes stored within the TPM)
Authenticated boot – a process by which a platform's state (the sum of its components) is reliably measured and stored. SRTM - Static Root of Trust for Measurements
Sealed Storage - encrypt data based on the current state of the platform or in other words, what has been measured (the PCR hash values stored in the TPM) - seal operation
Attestation - securely report to other parties the state of the platform, e.g., quote operation aka Remote Attestation.
As such you could use trustedgrub (SRTM - Static Root of Trust for Measurements) but not tboot which implements a DRTM (Dynamic Root of Trust for Measurements) aka TXT.
About "how TXT works" see this question.
It's like asking "What's the difference between a car and an engine?"
The TPM is a vital part of Intel TXT. Without it Intel TXT does not work.