I'm doing Hyperledger Fabric CA tutorial HSM2
(http://blog.daum.net/_blog/BlogTypeView.do?blogid=0ThNq&articleno=855&categoryId=45®dt=20130628125634)
I'm doing as the tutorial says but I don't know what slot and Token mean. Searching for a slot will only show me that slot is where you plug in your graphics card or LAN card.
*****************/src/lib/common$ softhsm2-util --show-slot
Available slots:
Slot 0
Slot info:
Description: SoftHSM slot ID 0x0
Manufacturer ID: SoftHSM project
Hardware version: 2.5
Firmware version: 2.5
Token present: yes
Token info:
Manufacturer ID: SoftHSM project
Model: SoftHSM v2
Hardware version: 2.5
Firmware version: 2.5
Serial number:
Initialized: no
User PIN init.: no
Label:
I want to know what is slot and token.
thank you :)
What you are looking at is the HSM, or hardware security module. It is a piece of hardware (or can be replicated by software, such as the softhsm you are using) to store and generate cryptographic keys. Of note, it is not required to use an HSM to operate Fabric.
But to answer your question, what is a slot, in am HSM it is simply the logical division in the HSM storage engine where the HSM token is stored. You need to initialize the HSM token and it will become obvious what these values are, mainly because they are all specified in the command:
softhsm2-util --init-token --slot 0 --label "ForFabric" --so-pin 1234 --pin 98765432
Again, the slot is the logical partition where it stored, the label is the name of the token, and the pin is essentially the access key.
Fabric provides a short document on setting the HSM up here:
https://hyperledger-fabric.readthedocs.io/en/latest/dev-setup/build.html#running-the-unit-tests
Related
I have a piece of software which I would like to lock down using a license key. This key contains the expiration date in unix timestamp format. To check if the license in valid in the software, I compare the current unix timestamp to the expiration date in the license key. Here's the tricky bit: I want to be able to allow the user to run the software offline without making a request to a server to validate the license (in essence, the user shouldn't require an external network connection to run the software).
Are there any strategies which can be used to prevent the user from simply changing the clock on their machine which essentially bypasses the license expiration?
I work for a company that provides two solutions for the problem of node locking a license to a device when that device does not have an internet connection.
I'd also start by saying that there's actually two parts to your question: How do you perform a license activation on a computer that does not have internet access, and how do you perform the license checks on the local machine, once you bound the license to that device.
If you don't node lock the license to the device, then anyone with the key you generated can just use it on an unlimited number of machines. For this you still need a way to communicate a device identifier back to the license server, even if it's not done through a direct internet connection.
Our first solution tackling offline node-locking does basically the same thing that our online activation does, except it's through a series of request / license files being exchanged between the client machine and the license server instead of Server-to-server interactions. The gist of it is as follows:
cyrusbehrVendor issues a license key for cyrusbehrApp and gives it to the end user.
End user enters it into the app, which generates a request file containing information on the device, and the key which is being used to activate the app (the file is / should be encrypted). The file is actually generated by the SDK that we supplied to cyrusbehrVendor, who imported it into their project and is shipped with the app. The end user takes this request file and uploads it to the License Server using our offline licensing portal.
The Offline licensing portal returns a license file that contains all the license information associated with that key, and can only be used by the device that requested it. The End user inputs this license file back into the app, which gets parsed by the SDK, which is used to configure the state of the application (according to the entitlements granted by the license). The SDK will also create a local license file to check against each time the app is run, for example.
Most Software developers might find this a "good enough" solution to offline licensing that isn't toooooo inconvenient for the end-user. However, if your requirement also does not allow for files to be exchanged, or files cannot leave the target machine, we also provide an air-gapped solution to unlock license policies shipped with your app. We designed our air-gapped license activation in the following way:
You ship your app with our SDK along with license policy files.
You issue license keys for your app that can be used to unlock a specific license policy.
through a series of code exchanges (rather than file exchanges), a license gets bound to a device, and allows a specific license policy to be used.
Concerning your question about local license checks and having some sort of anti-clock tampering mechanism, you can do the following:
Read and Store a time stamp of the system clock on the last license check. If a subsequent license check has a timestamp that occurs prior to that time, then you know there's something going on with the clock being changed. You can either disable the license, or just throw an exception and don't let the app run until a license check with a timestamp in the future. Also, be sure to use UTC, since timezone changes can and do happen.
I implemeneted my device by extending the Assistant as documented in instructions
I can see my device registered with the traits:
googlesamples-assistant-devicetool list --model
Device Model Id: assistant-19etc....
Project Id: assistant-19etc....
Device Type: action.devices.types.LIGHT
Trait action.devices.traits.OnOff
Trait action.devices.traits.StartStop
However when I say Ok Google, turn on as mentioned in here
I receive the event :
ON_RECOGNIZING_SPEECH_FINISHED:
with the text
turn on
but not the action
ON_DEVICE_ACTION:
Instead the assistant says to me:
Sorry power control is not yet supported
Is the Assitent library/service limited to regions, or is there any other limitation why I do not receive the actions back despite I followed the instructions and according to them all seems to work?
After playing hours with assistant, and reading the docummenattion over and over, I found out , there is a hidden meaning and missing instructions hidden behind this sentence:
When you run the sample, it will generate a device instance for your particular device. This device instance will be associated with the device model that you specified to run the sample. Find the device instance ID in the output for the sample. You will use this ID to update your device so you can use Device actions.
device_model_id: my-model device_id: 1C3E1558B0023E49F71CA0D241DA03CF
What the document forgot to mention is that you must not only register the model but you also have to register the device as writen in reference
After registering the device with all the needed fields including nick I was able to receive the actions.
And this is exactly where you will need the device id from that sentence above... Somehow this step dropped off from the documantation :-)
googlesamples-assistant-devicetool register-device [OPTIONS]
Registers a device instance under an existing device model.
Device instance fields must start with a letter or number. The device ID
can only contain letters, numbers, and the following symbols: period (.),
hyphen (-), underscore (_), and plus (+). The device nickname can only
contain numbers, letters, and the space ( ) symbol.
Options:
--device TEXT Enter an identifier for a device instance.
If the device ID already exists, this
command will update the device instance. If
it does not exist, this command will create
a new device instance. This ID must be
unique within all of the devices registered
under the same Google Developer project.
[required]
--model TEXT Enter the identifier for an existing device
model. This new device instance will be
associated with this device model.
[required]
--nickname TEXT Enter a nickname for the device. You can use
this name when talking to your Assistant to
refer to this device.
--client-type [SERVICE|LIBRARY]
Select the type of the client. Use SERVICE
if using the Google Assistant Service or
LIBRARY if using the Google Assistant
Library. [required]
I making a new app and want to submit to app store.
But at the time of final submission
there is check for Export Compliance.
What should I Check Yes Or No.
I use https url in my app.
Please Help Me .
Thanks In Advance.
When you know that you ARE export compliant you can put this in your Info.plist:
<key>ITSAppUsesNonExemptEncryption</key>
<false/>
This will prevent App Store Connect from asking you questions about export compliance.
If you are using https in your application, you will need to answer yes to this question, even if all you are using is built in mechanisms to communicate over https. The good news is that you no longer need to get the Encryption Registration Number (ERN) - the current requirements (as of August 2017) are that you just need to submit the annual self classification report to the BIS(Bureau of Industry and Security). To submit a self classification report, follow the instructions on item 13 in this FAQ: A sample Self Classification report can be found here.
For a great write up that talks about both sides of the story (apps that only use common / freely available encryption, like SSL, as well as apps that have their own, proprietary encryption, see this Medium post.
Please don't listen to other people who state that they just answer no to this question to make things easier when submitting an app.
As of February 2018 this is the process to file an Annual Self Classification Report to BIS (Bureau of Industry and Security):
https://www.bis.doc.gov/index.php/policy-guidance/product-guidance/high-performance-computers/223-new-encryption/1238-how-to-file-an-annual-self-classification-report
To get a ECCN (Export Control Classification Number) for a HTTPS mass market iOS app follow, these steps.
Download the quick reference guide to classify your app.
https://www.bis.doc.gov/index.php/documents/new-encryption/1652-cat-5-part-2-quick-reference-guide/file
For a basic HTTPS iOS app used to securely access a webpage or transfer a file use
5D992 which is Information Security” “software” not controlled by 5D002.
If your app contains more encryption functionality, then reference the policy guide. https://www.bis.doc.gov/index.php/policy-guidance/encryption
Might not be what you want to hear, but you will need to review the policy and correctly categorize the app and get the correct ECCN.
Now go to the SNAP-R form. https://snapr.bis.doc.gov/snapr/
To get to the form from the BIS homepage.
https://www.bis.doc.gov/index.php
Then select Licensing -> Simplified Network Application Process Redesign (SNAP-R)
Register Online for a SNAP-R account.
https://snapr.bis.doc.gov/registration/Register.do
The Bureau of Industy and Security will return a CIN application ID quickly via email.
Return to the main SNAP-R page with the CIN issued number and login.
Select "Create Work Item "
The Type will be "Commodity Classification Request"
Reference number is 7 digits. I used my phone number.
Create
Fill in Contact Information.
Leave License Information Blank
Fill in Company Designation any info missing. When you created the CIN this info was requested.
Other Party can be left blank.
Now for each app you want to register, fill in a Export Item and press Add Export Item. Multiple apps can be submitted on the same request.
ECCN will be 5D992
APP can be left blank. It is the Adjusted Peak Performance"("APP") which for a commodity iOS app is not required.
Product/Model is the name of the app in the App Store.
CCATS can be left blank.
Manufacturer is your company name.
Technical Description - briefly describe the apps function and how HTTPS is leverage. Keep it simple. They are interested if the app is a security risk and how encryption is used.
example:
AppName is distributed as an Apple iOS App. It uses HTTPS to download/upload daily updates to and from xxxx. The download is used to generate a table. An In-App .99 cent purchase expands the table results to include xxxx.
Additional information explains in more detail how HTTPS has been implemented.
The HTTPS file transfer is a URLSession data transfer task found in the Apple Foundation library. The iPhone automatically performs the download of the published data in csv file format, using the HTTPS protocol for a secure transfer.
Make sure you saved all your drafts. Check for errors. Then submit.
The turnaround is pretty fast. Mine took around an hour. But I am sure it varies.
The other option is once a year you can submit an Annual Self Classification Report. But if you have a SNAP-R CCATS number you are not required to submit a Annual Self Classification Report.
https://www.bis.doc.gov/index.php/policy-guidance/encryption/4-reports-and-reviews/a-annual-self-classification
This is very simple. Download the sample csv file. Delete out the sample data leaving the headings. The heading are required. Fill in the columns. The column Authorization Type is MMKT. Item type Other: HTTPS File Transfer. Save the file and submit.
The BIS SNAP-R hotline [202-482-4811 DC, 949-660-0144 CA] and the Encryption Hotline for the annual submission [202-482-0707] are both very helpful. Last point, the BIS has helpful set of YouTube video.
https://www.bis.doc.gov/index.php/online-training-room
Hope this helps.
From Complying with Encryption Export Regulations: Declare Your App’s Use of Encryption:
Typically, the use of encryption that’s built into the operating system—for example, when your app makes HTTPS connections using URLSession—is exempt from export documentation upload requirements, whereas the use of proprietary encryption is not. To determine whether your use of encryption is considered exempt, see Determine your export compliance requirements.
So Apple says that for usual HTTPS scenarios, you do not need to upload export documentation for your app.
When we talk about securing iOS application we often forget to secure most critically sensitive information such as secret, key, token, encryptionKey. This information is stored in iOS binary. So none of your server side security protocol will help you.
There are lots of suggestion that we should not store such information in the app but store in the server and get it via SSL secured web service call. But this is not possible for all application. E.g. if my application does not need web service at all.
In iOS app we have following option to store information.
UserDefault: Not appropriate for this case
String Constant: Not appropriate for this case. Can be reverse
engineer to retrieve or just use strings command
Secure Database: Store in Secure and encrypted Database. But again have responsibility to secure database username and password.
KeyChain: Best to store critical info. But we cannot save information before installing the app. To store in the keychain, we first need to open the app, read from some source and store in the keychain. Not appropriate for our case either.
Custom Hash String Constant: Not to directly use secret, token, key from service provider (mixpanel, paypal), instead use hash version of that information from custom key. This is also not perfect solution. But add complexity during hacking.
Kindly send some awsome solution to this problem.
If you don't want to use your own backend then use Apple. You can configure On Demand Resources and keep data file with your key, token, any secret on Apple server. After first download you can write this data to Keychain which is secure enough. I'm guessing networking between iOS and Apple server is also secure enough.
On-Demand Resources Essentials
Accessing and Downloading On-Demand Resources
1) Internet Connection Required
1.1) Push Notifications
Great way to have a secure data exchange could be to use (silent) push services from Apple, those use the apns and send data through https - more Details 3.1
1.2)
A more or less similar approach is also used when distributing new user certificates to already deployed applications, if a reinstall of the application is no opportunity AND the application requires a working internet connection anyway.
Downside: working network connection required and basically the information is coming to the application, when it is already being executed => seems not to be appropriate for your case. (see step 4)
2) Static data (as there will be no exchange without network connection / communication partner)
Encryption of data with private key being provided in the bundle itself. Whether it is now a string or a hash, which can be reverse engineered with functions you got emebedded in your application.
Since iOS9 it is pretty hard to decompile iOS applications and basically you will mainly have a look into the provided header-files. So if you had such a function, string, hash value or whatever, make sure you got it in your .m-file!
But again: if the information is not device or user specific, just a secret across your own micro environment, valid across all devices, you would have to provide the encrypted data AND the decryption method in the same bundle, if there is no update process / information exchange or something else, you can think of.
Good for encryption:
iOS System.Security https://developer.apple.com/reference/security
or simply openssl
The difference between your described keychain approach is:
You got a value, which WILL be encrypted and stored securely.
(2) describes the approach to have an encrypted and stored (in bundle) semi secure value, which WILL be decrypted
3) Information exchange
You describe critical data, which was hashed by another instance. Great! - Make sure, relly make sure, the instance you are talking to is really the instance you expect to be (Network Hooking prevention with ssl certificate pinning etc, but even here you might have intruder (men-in-the-middle)). And you will (probably) have a certificate being provided in your application bundle, to ensure the authenticity of the communication server - here you go again, data that is supposed to ensure a secure process between certain instances of your micro environment. Nevertheless, this data is being provided in your application's bundle.
3.1 Secure Information Exchange extended - Silent Push
Make use of Apple's servers to exchange your secrets for this purpose. If you just need to exchange small data chunks. I would recommend to use silent push notifications to the user, those do even work without explicit permission from the user. Huge advantage: In case your secrets or keys change, you can inform users as soon as possible about the change. They will likely only need the change, when they receive new data, which should reliably work in most cases. Exception: Data exchange in local networks or via bluetooth, in this case I would recommend to provide a notification to the user to have the requirement to update a local decryption key. Or exchange the key in this format as well. Once again: I am leaking some detailed information about your environment architecture.
Downside: You don't know, whether a user just used your app for the first time, until the user "tells" you so.
https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//apple_ref/doc/uid/TP40008194-CH8-SW1
3.1 Secure Information Exchange extended - In App Purchase
Use a frree In-App Purchase for the user to get the data to your phone. Good point here: you can provide larger data chunks easily, as this should be an active request by the user, the user does expect certain processing time and should also be aware of the fact to require a working internet connection.
Downside: User would have to select this on purpose. Up until then the app would not work accordinly.
https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Introduction.html#//apple_ref/doc/uid/TP40008267
So, it just slightly differs from the approach (2) in its basic idea.
In short: Can you provide additional information, what kind of data you need to encrypt/want to store securely and whether you will have a network exchange or not?
Would need some more information here :-)
I would like to emphasize once again that an application on iOS is not that easy to decrypt anymore, even decompiling would not get everything, you expect it to get. For instance decryption tools like dumpdecrypt were only working properly up until iOS 8.4
It seems to me that the best way to do this is using the built in CloudKit. You can save your secrets in the CloudKit Dashboard and then fetch them on startup. Since CloudKit is only a transport layer you'll have to store the app secrets in the KeyChain.
I know you mentioned the KeyChain not being ideal for your use case (not sure why), but this is a good way of not including the secrets in your app. You can't get around fetching your app secrets from another source.
CloudKit access is secured using the system iCloud account and if there is no iCloud account you still access the iCloud servers securely. Another added benefit of this is that you can change your app secrets at any time, so if you want to be even more secure you can implement a rotation schedule.
Learn more about CloudKit
Cocoapods-keys might be a best option.
From cocoapods-keys doc's
Key names are stored in ~/.cocoapods/keys/ and key values in the OS X
keychain. When you run pod install or pod update, an Objective-C class
is created with scrambled versions of the keys, making it difficult to
just dump the contents of the decrypted binary and extract the keys.
At runtime, the keys are unscrambled for use in your app.
The generated Objective-C classes are stored in the Pods/CocoaPodsKeys
directory, so if you're checking in your Pods folder, just add
Pods/CocoaPodsKeys to your .gitignore file. CocoaPods-Keys supports
integration in Swift or Objective-C projects.
Check out this link for installation, usage and more info : https://github.com/orta/cocoapods-keys
I agree with #Lobsterman and believe that the best way will be to use a combination of these.
Don't include the secret information in the app initially.
Deliver the secret key either as in-App purchase content ,on-demand resource or send it through push notification. This will add the benefit of changing the key periodically if you want and the change will take effect without any additional effort.
Add the entry to keychain access once the content is delivered.
If the data is extremely sensitive then it should never be stored offline on device because all devices are crackable. If you still want to store on device then keychain is one option for storing data securely, However it's encryption is based on the pin code of the device. User's are not forced to set a pin, so in some situations the data may not even be encrypted. In addition the users pin code may be easily hacked.
A better solution is to use something like SQLCipher which is a fully encrypted SQLite database. The encryption key can be enforced by the application and separate from the user's pin code.
I'm considering using the CFUUIDCreate API to build a database in my server to measure what percentage of users of each of my apps are running which version of iOS (to help me make a decision on iOS minimum supported version for future development).
My question is: Should I ask the user for permission to send the (anonymous) UUID / iOS version data pair to my server, or is it OK to do it automatically?
I ask because I could bet on the safe side and ask anyway, but most users would feel intimidated by the technical details and most likely decline. Also, the longer the text in an UIAlertView, the more likely the user won't read it.
Will Apple reject my app if I don't ask? Even if they don't, do you think I should always ask the user for permission to send this anonymous data?
What's everyone's experience implementing this kind of functionality?
OK, this is what I'm going to do, based on Nikolai Ruhe's answer but improving on a pitfall I just discovered.
Suppose user John Doe installed my app on his iPhone running iOS 5.0.
On the first launch, the app sends an anonymous request to my server that effectively increases by one the counter for 'Devices running iOS 5.0'. The app records this event and the iOS version (in User Defaults or Keychain) and does not send any further requests as long as the locally stored OS version string and the current one (returned by the system) are equal.
The next week, John upgrades to iOS 5.1 and launches my app. The app detects the OS version discrepancy and sends a new request to my server.
But if this only adds one device to the 'iOS 5.1' population, John's iPhone is now being counted twice: once as "Devices running 5.0" and once as "Devices running 5.1".
So to fix this, my HTTP request should look like this:
http://myserver.com/my_stats_scripts/index.php?app_id=com.myCompany.myApp&new_os_ver=5.1&old_os_ver=5.0
So my database can increase the number of 5.1 devices and decrease the number of 5.0 devices by one.
Of course, on the first request, the HTTP parameter old_os_ver is set to empty, and the server treats it like a new device.
If I pull this right, I no longer need UUIDs. But I am still sending system info covertly to my server. I think I'll also disclose this on the Terms of Use.
You should definitely ask for permission. The crucial bit here is that your data collecting might be anonymous, yet it can be used it to track individual users.
Web browsers send a user-agent string with every request. The difference is that they do not send a universally trackable id that would never change.
So the problematic piece in your proposal is the UUID. Why not just leaving it out? Your app would send an anonymous request once and locally store the transmitted iOS version. When the user upgrades the OS, you send another request with the new iOS version and an update count.
Using this scheme you would not transmit trackable data and still get a proper usage-by-os statistic.