An organization's employee are involved in a network. Each transaction they send will need to be signed against their private keys and will be encoded in the transaction they send.
1) Where are the private/public keys stored? Are they stored locally on an employee's laptop?
OR
2) If the organization's employee use different computers to perform daily tasks, would the pub/piv keys be stored on cloud?
Thanks!
Nice solution to store it on cards as described here
Private key protected by password and stored on card, we can use usb card readers to load key on device and use it to sing requests.
Difference to store certs on devices instead of cloud is that personal devices controlled differently then cloud - you can't protect information if you can't guarantee physical storage protection.
And it is always a question how to maintain CRL.
Related
Sorry for maybe a silly question. I want my app to use iCloud for backing up and synchronising user's data, assuming that CloudKit works with user's cloud. However it may not be the case.
I have two cloud accounts: personal and developer's ones. My macOS is logged to the personal iCloud account, so I expected my macOS app to use it. However CloudKit Dashboard shows cloud containers for the developer's account instead.
Also iCloud design guide says "CloudKit provides a way to store data as records in a database that users of your app can share" which implies that the cloud data represent a single instance for all users.
So, which cloud: user's, developer's, or a separate one (designed especially for app containers) is used by CloudKit? It case a separate cloud it used does it count as a developer's storage?
The CloudKit container for your app contains two databases; A public database that is accessible to all users of your app and a private database that is only accessible to the current user.
Individual records in the private database can be shared with another user via a CKShare.
Data that is stored in the public database comes from your app's storage allocation; the amount of storage you get for free depends on the number of app installations.
Data that is stored in the private database is stored in the user's iCloud storage and counts against their storage allocation.
From the CloudKit Quick Start document
An app has access to both a public and private database in each container. The public database is for storing user and app data that is shared between all instances of the app. By default, all users can read the public database, but they need to enter iCloud credentials to write to the public database. There’s a private database for each user of your app, but the app only has access to the private database of the current user. The user has to enter iCloud credentials for the app to read and write to the private database.
Information is also available on CloudKit Overview page - Check the footnotes at the bottom; private storage comes from the user's free 5GB allowance (they may purchase more). Public storage comes from your app's allowance.
I have static key in my iOS application. By using that key I am encrypting credit/debit cards and sends it to server for future use. And I am using same key for decryption of card.
Now I can't use dynamic key by any key generation algorithm as I want to decrypt my card later on. So, Every time I require same key.
So, My question is how should I store my key or where I should store my key as it'll be most secure? or Can I manage this stuff by generating dynamic key every time? If yes then how?
Many iOS applications like Amazon, Uber etc are storing the card information in their server! How they people are managing this stuff?
Any help will be appreciated! Thanks!
If you need to ask this question then you are already breaking PCI compliance. Your customers credit card information should never touch your server, encrypted or otherwise. Most payment gateways handle this for you. There is very little reason why you should be doing this yourself.
If you do need to handle this yourself, and there are very few cases where you do, simply symmetrically encrypting the card information in your app is not the way to do it. Literally anyone who can download your app can decrypt other customers credit card information.
The correct approach would be to transport card information to your server secured with TLS, then encrypting and storing the key information in a HSM server side. If you can't manage this, then you are not PCI compliant and will be legally responsible.
If your business operates, or has service available to customers in the EU, then you could suffer very heavy fines for poor handling of consumer credit card information.
I have a developer account and I'm developing an app for someone. I want him to be able to change datas in CloudKit so I want to use his iCloud account(He doesn't have a developer account, just personal account). However, i don't know how to differentiate my developer account and his iCloud account.
Thank You
I believe CloudKit's notion of public and private databases may achieve what you need to do. As a reference, I am referring to slide 45 in Apple's WWDC presentation on cloudkit (http://devstreaming.apple.com/videos/wwdc/2014/208xx42tf0hw3vv/208/208_introducing_cloudkit.pdf)
Considering that each app has a container, and that container includes 1 public database (that all users of the app can access) plus a multitude of private databases (one per user), if the data you're storing isn't private, then consider storing it in the public database. You can modify it as needed during development by being logged into your iCloud account, and your client can modify it as well by being logged into his iCloud account. (Apple docs say the public database is stored in the App developer's iCloud space)
If you store the data in the private database, however, it will be written to an instance of the private database belonging to the currently signed-in user. So anything you write would go into a private database instance (which Apple docs says resides in each user's personal iCloud space) and anything he writes would go into his private database instance. Until recently, that was the end of the story. However, now, cloudKit supports CKShare which, in a nutshell, allows a user to grant access to specific shared items inside their private db. So you could still write the data to a private DB but allow access via a CKshare.
Finally, there's another option, but I don't recommend it. In the device settings, you can log out of iCloud and log back in as another user. In which, you're still developing on your device, but you're logged into iCloud as your client. This has many drawbacks, though. First and foremost, credential sharing is always a bad security practice. But, probably a more immediate consequence will be your device will no longer be sharing with/backing up to your iCloud account, but instead with the client's.
It's hard to give more specific advice without better understanding the scenarios you're implementing.
** update based on OP's comment **
I see now. Using the development cloudkit dashboard probably isn't going to work. AFAIK, you must log in with a development account, not just an iCloud account, to use the cloudkit dashboard. So your client won't be able to get in at all, anyway. You could add your client's email address as a member of your development team, which will let them log into your cloudkit dashboard; however, that also gives them access into portions of your iTunesConnect as well. And, it really won't scale to support additional users of your app.
I am new of iOS swift 3 development. Now, I am working on a project which needs encryption, message authentication code(MAC) and Hashed-base-MAC. These algorithms require secret keys. I know that it is a bad practice to hard-code the keys inside the code, like:
let key = "secretkeyabc123"
Searched and read some articles like:
In iOS, how can I store a secret "key" that will allow me to communicate with my server?
Since other people may perform reverse engineering, I am finding a way to protect my keys. Requirements:
No hash the key. Time allows to crack it, or with hashed table and dictionary
May not connect to Internet (My app. is an offline app. If your answer needs to connect to Internet. Yes, please point it out. I will think about it)
It is a static key. It may change monthly
It is a symmetry key.
Codes, concept or other things are welcome. Thanks!
Don't store the key at all. Perform a Diffie-Hellman key exchange to start an asymmetrically encrypted channel, and use this channel to send across a symmetric key to the client, which can be used for subsequent client use.
Check iCloud Keychain (based on your tags [ios], [swift], [key]).
It functions as a secure database that allows information including a user's website login passwords, Wi-Fi network passwords, credit/debit card management (though without CVV), and other account data, to be securely stored for quick access and auto-fill on webpages and elsewhere when the user needs instant access to them. They are always stored encrypted using 256-bit AES encryption, are stored on device and pushed from iCloud between devices, and only available on a user's trusted devices.
I have a string encrypted using RNCryptor v2.2 ObjectiveC library.
After encryption it is stored locally on iPhone.
When want to get the string back, before decryption, I want to make sure that the encrypted is not tampered (like manually changed a character).
How can I verify this?
Thanks in advance!
The theoretically correct answer to your question is that whatever you do in your app locally on the device, you will not be more sure whether your data has been tampered or not compared to doing nothing. You will need to use an external, reliable agent such as a https web server to store some information about your data.
Let me explain this briefly. iOS already gives sufficient protection to the data of your app with its data sandboxing model assuming that the device of the user in not jailbroken. This means that there is no way to alter the private data of your app (saved in the standard Documents, Caches, etc. folder of your app). On the other hand a malicious user who wants to modify the encrypted information stored in the private folder of your app, can jailbreak the device. In this case he will have access to everything and can read and write any private folders.
Some could say that you can create a hash or a digital signature of your data and store it on the device. But if the device if jailbroken the intruder would have access to everything, including the binary code of your app (Objective-C can be reverse engineered without too much effort) and so the hash generating algorithm, the salt or the private key of your digital signature. So he could easily manipulate the digital signature or the hash as well.
You should evaluate the risk of your data being tampered. How much effort worth tampering your data? If you are storing banking information and count about 1 million of users, you should take seriously the risk that somebody could jailbreak the device, reverse engineer your app and tamper your data. If you are storing session tokens of a photo-sharing app, maybe you can just leave it as it is and trust in the sandboxing of iOS. Also it is very important that jailbreaking the device needs active participance of the user so it is not possible to do it remotely, without the consent of the user. This means that the data can not be tampered without the consent of the user.
If you really need to protect your data then the only way is to use an external service that you trust and that can provide your an external security regarding to the device. You could send your sensitive data to a web server through https, let the web server sign it with its private key and resend to you the signature that you can store calmly wherever you want. Every time you need to access to your sensitive data you could verify the signature of the data (and the validity of the signature with the public certificate of the server). As the private key is stored on the remote server, you can be sure that nobody can access it and it can not be used to sign a tampered data.
RNCryptor includes an HMAC to detect this. If the ciphertext is modified, it will not decrypt. You'll get an error ("HMAC Mismatch").