I'm making a program that has a feature to sign in using ONLY! A user fingerprint image from iPhone and matches it among various fingerprint images in the database, so if there is any possible way to get fingerprint image from the user in iPhone?
(basically, I want to make iPhone works as a fingerprint scanner).
Many thanks.
No, absolutely not possible. It's against the Apple policy and I would say even their core values. And it is understandable as it would potentially be a very dangerous capability.
From the Apple documentation on TouchID:
To maximize security, your app never gains access to any of the underlying authentication data.
But you can use the provided authentification API (e.g., to safeguard a given sensible operation).
Short answer: API only tells if the fingerprint matches or not, not more than that.
I doubt there is a way due to privacy concerns, not even developers should be supposed to have access to it. Even if that was allowed, security measures should be taken such as having it hashed.
Related
We have a requirement where we need to login in to our application using fingerprints. We do understand that apple touch id can be used for authentication purpose and only returns success or failure in the response.
However, in our case one iPhone device will be shared by 5 to 8 users and we need to map an unique userId with each saved fingerprint to identify the user.
Is there any way to map a userid with the saved fingerprint (any unique number returned from an api like Fingerprint1, Fingerprint2 will do)?
Or Is there any alternative solution to login to our iOS application using biometric data?
We dont't want to add an extra fingerprint scanner device.
No, You can't achieve this in iOS. According to Apple about biometric
Touch ID doesn't store any images of your fingerprint. It stores only
a mathematical representation of your fingerprint. It isn't possible
for someone to reverse engineer your actual fingerprint image from
this mathematical representation. The chip in your device also
includes an advanced security architecture called the Secure Enclave
which was developed to protect passcode and fingerprint data.
Fingerprint data is encrypted and protected with a key available only
to the Secure Enclave. Fingerprint data is used only by the Secure
Enclave to verify that your fingerprint matches the enrolled
fingerprint data. The Secure Enclave is walled off from the rest of
the chip and the rest of iOS. Therefore, iOS and other apps never
access your fingerprint data, it's never stored on Apple servers, and
it's never backed up to iCloud or anywhere else. Only Touch ID uses
it, and it can't be used to match against other fingerprint databases.
Now come to main point.
Now days iPhone X series is more popular than other, and they don't support Touch ID, also you can store only one Face ID per device. not like the Touch ID (with multiple finger).
Or after certain wrong try of finger print the device will locked and you have provided Passcode, This is also one per device.
No, there's no way for you to know how many and which finger was used for biometrics, the secure enclave only lets you know if the biometric check has passed or not.
I have a client who wants to create an app that checks for a user's neck posture. I have seen some weird implementations online which aren't very sophisticated so I came up with a way of doing it but I required 1 component which involves facial recognition while the App is in background mode, meaning the user doesn't have the app open and its just running n the background. I've read online Apple does not allow this feature for security reasons and I am wondering is there any possible way to convince Apple to allow me to do this? Are there special cases where we can implement it?
for example
The app checks the phone's Pitch position
The app checks wether it can detect user's face
The app uses these two properties to determine how well the user's neck is aligned with the app.
This is not currently possible. If you want to convince Apple to change this at some point,
Go to http://bugreport.apple.com/ and file an enhancement request
Include a highly persuasive argument as to why they should want this in iOS. Be sure to cover the security concerns that prevent it from already being possible.
Wait. Probably a long, long time.
After successful purchase I save receipt+transactionID into NSUserDefaults. Same information is sent to server to keep a record.
Later(on demand) when user want to download content from my own server, my app will send receipt+transactionID to server. It will find stored receipt by transaction ID sent from app, verify both stored and new receipts with Apple. If some of the keys matched then provide downloadable content.
However, nowadays it's not hard to get hold of NSUserDefaults and extract receipt+transactionID. Even if I place information in keychain, it's possible to capture receipt from internet connection.
Now if someone will have receipt+transactionID, can send a request to my server and get content from any PC. How can I patch this logic without using cryptography?
Although you can patch your logic to make it harder to break, if you want real protection you need some kind of cryptography. You do not need to apply it explicitly - something as mainstream as switching from HTTP to HTTPS will often do the trick.
The three places where you need to protect your sensitive data are on the device, on the server, and in transit.
To protect the data on the device, store it in the Keychain: after all, storing small chunks of sensitive data is the main purpose of adding Keychain to the array of storage possibilities on iOS.
Server protection is a large topic that has been treated in numerous online and offline publications; for the purpose of this answer I assume that your server is adequately secured.
What is left is protection of your data in transit between the device and the server, and between your server and the Apple's server. You can use HTTPS for achieving transport-level protection.
Note that adding all these levels of protection does not make your data absolutely secure: an entity with a lot of time and resources (e.g. a government of an unfriendly country) could potentially discover your keys - for example, by disassembling the physical device, and inspecting the data coming out of the CPU with a logic analyzer. However, the point of this exercise is not to achieve the absolute protection, but to make it prohibitively expensive to break your security scheme. To that end, a combination of Keychain and HTTPS should achieve the goal of making it more expensive to break your protection than to buy your content legally.
I need to develop some simple demonstration of an application reading a file over HTTPS and saving it to the local memory (internal or external) of an iOS device (e.g., an iPhone), in a way that it is only accessible to it. So, application-specific file encryption is required.
The "Advanced App Tricks" page of the Apple iOS Developer Library, in the "Protecting Data Using On-Disk Encryption" section, seems to imply that a file encrypted on disk, via either Default (i.e., iOS filesystem) or "Complete" Data Protection, would be accessible by all applications, after the user types the device's lock code.
If that is the case, could someone please suggest the best way of implementing file encryption per-application on an iOS device, with a password request when a user tries to open the file? Any sample code would also be very helpful.
Also, does "software encryption" apply to iOS anymore? Both Default and Data Protection encryption seem to be hardware-based.
Thanks!
Application files are not accessible between Apps. Each App is individually sandboxed.
In all cases the document is talking about the access available to "Your App"/ It is never accessible to another App. But see below. Sone of the protection options help cover what and when "Your App" has access to the file when in the background.
JailBroken iOS devices will have greater file system access so adding "Data Protection" will protect from this vector.
See the document session on The iOS Environment and particularly the section "The App Sandbox" iOS Environment
Hardware encryption: There are a few things that hardware encryption provide. 1. Speed. 2. The encryption method can not be changed, that is as with software encryption there is no code that could be compromised. 3. The key can not be accessed. The key is in some manner placed/created in the hardware and the hardware will does not allow read access (there are occasionally very secure export capabilities). The device is asked to perform crypto functions on data and returns data. Examples of this are smart cards, HSMs, TPMs and TPM Equivalents, the iPhone has a TPM Equivalent and that is used for the Keychain. By chance my wife and I were discussing this very topic yesterday. :-)
As far as I know, for encryption of bulk data, iOS does use special hardware instructions to aid AES encryption for speed but that would not be considered hardware encryption due to the key being available in software. There is a little guessing here due to the lack of information about the Apple A-series ARM chips, it is true of the Intel chips in Macs.
The client is concerned about safety of the data application uses and stores locally on device (e.g. they want to prevent reading our data files even on jailbroken iPhones). So I wonder - what are the possible ways to ensure data safety on iPhone?
Edit:
I'm thinking about 2 ways of storing data - a bunch of xml files (maximum size - about 1MB) or sqlite database. I'm more inclined to the 2nd variant but still not sure
You might want to check out this article - Protecting resources in iPhone and iPad apps. It talks about a scheme to encrypt app resources at build time, which can then be decrypted when needed by your app. Decryption happens in-memory so unprotected temporary files are not left on the filesystem. You can even load encrypted HTML, PDF & images straight into a UIWebView.
For transparency's sake: I wrote that article and it is hosted on my own website.
Any time code is running on physical hardware that's out of your control, it is vulnerable - the iPhone must have the ability to decode the data for it to be usable, and if the iPhone has that ability, so does the user. If the data is valuable enough, someone will break your encryption.
The movie industry spent millions on their DVD DRM. It got cracked in a few weeks.
The commoncrypto library, available on the phone, supports symmetric encryption. You can store the key in the keychain, which is itself asymmetrically encrypted. The key to decrypt the keychain is baked into the hardware so you'd need to go to some lengths to retrieve the data.
(e.g. they want to prevent reading our data files even on jailbroken iPhones). you may use localytics mobile analytics(open source) to find out whether the application has been used in Jail broken iphone or not.. They have premium options also..Lot of mobile analytics are available.you can check..