I need to generate PDF in my app (which has been done), and then, mark it with a digital signature for security purposes(which still needs to be taken care of).
Here, I am not talking about simply pasting an image (containing signature) in the pdf file; but actually use public-key/private-key for this purpose.
I have Googled a lot, but all I could find was how to add a signature image in the pdf. Does Apple provide any libraries for digital signature?
Note that you also need to understand and discuss (with the right business person) the security of the digital certificate(s) used for signing.
If you want to ensure that no one/nothing except for authorized people and processes will be able to sign with the certificate, then the certificate must be stored in a secure hardware device.
The two common secure signing system types are smart cards and signing servers. Smart cards can be difficult to interface to. Signing servers are easy to use via network APIs. Example signing server APIs. Signing servers are available as web services if you want.
Related
This might not be a direct code question, but it's one that comes up frequently on SO and I find very useful to read.
App Store - Help answering “Missing Compliance” (using Expo + Firebase)
Does my application “contain encryption”?
ITSAppUsesNonExemptEncryption export compliance while internal testing?
I don't live in the US and therefore don't navigate freely in their law system or stays up to date with changes. But using american products and platforms like the Apple App Store means that I have to comply with the national rules and policies.
There is this one thing about encryption compliance whenever I submit to the app store. It always ask me if I'm using encryption. The answer is yes - since fetching like OTA updates are https. The SO questions are often so yes to the first and no to the rest if https is the only encryption used.
BUT what if you are using encryption to authenticate a user. Then it seems like it has to be yes to encryption and yes to this question:
Does your app qualify for any of the exemptions provided in Category 5, Part 2 of the U.S. Export Administration Regulations?.
Here is what I don't get. If this is the case for US compliant mobile apps - do I need to report to US authorities if I deploy a web site that do the exact same type of authentication logic
There is a lot of great material on how to build a good authentication system - but have never come across a mention of
"BTW ☝️ don't forget to report to the US authorities that you authenticate your users with encryption"
First IANAL, so take this a professional experience, not legal advice. There is no requirement to notify any specific US authority that you use encryption in your auth process. I suspect that these questions are asked because of the ITAR Regulations that deem certain kinds of encryption to be "arms" and therefor not legally exportable from the US (Discussion of ITAR and Crypto here) given you are already in (presumably legal) possession of whatever encryption scheme you are using, these rules do not apply to you. There may be more specific regulations if you have an affiliation with the military or intelligence agencies of the US or any other country.
I'm trying to setup Kahuna for my iOS app, and haven't been able to find a clear answer - the docs says that the secret key is meant to be used with the API Key for authenticating requests, but I can't find anything that states clearly if either of these should be kept secret/out of source code. Are these safe to put in my code, or should they be kept on the server side?
Thanks
Are these safe to put in my code, or should they be kept on the server side?
Short Answer is no for keeping them on the mobile app code and yes to keep them on the server side.
Why?
Because they will be static secrets in your mobile app code, thus they are easily extracted by using any reverse engineer tool, like using the Mobile Security Framewrok(MSF) to decompile the app binary.
Alternatives?
Well you can try code obfuscation, to generate the secrets dynamical in the mobile app or to store the secrets in the iOS keychain, but once more they can be reverse engineered at run-time, once more by using the MSF tool.
Possible Solution?
The best approach is to use a Mobile App Attestation service to protect the connection between the mobile app and the API server, that will guarantee at run-time that your App is not being man in the middle attacked, being tampered with, that is not running in a rooted or jail broken device and that is the same original one uploaded into the app store. This is done in the background without impacting the user experience by using an SDK integrated in your App and a service running in the cloud.
With this guarantees in place we don't need any-more to store secrets in the mobile app for Authentication, Authenticity and Integrity purposes, thus any access to third part services within the App can now be delegated to the API server that will be able to do a better job of protecting all the necessary secrets to access the third part services, like storing them in a vault.
You can find a Mobile App Attestation service in Approov(I work here) that provides SDKs for several platforms, including iOS. The integration will also need a small check in the API server code to verify the JWT token. This check is necessary for the API server to be able to decide what requests to serve and what ones to deny.
When submitting an app that contains cryptography, I know there's a checkbox you must check, as well as subsequent questionnaire you must answer. And if the app contains cryptography you need to go through complex Exporter Registration and Reporting process.
There are three specific cases I'm curious about:
1. Cryptocurrency wallets
One of the "exemption" clause says:
(ii) your app uses, accesses, implements or incorporates encryption for authentication only
Does this exempt the app from having to go through all the complicated government approval process? Most cryptocurrency wallets only use cryptography for signatures and authentication, but I'm not sure how this applies to this case.
Simply put, do all Bitcoin wallet app developers have to get government approval before submitting the app?
2. End-to-End encrypted messaging apps
How about end-to-end encrypted chat apps? Do I have to go through the approval process?
I'm talking apps like Signal and whatsapp.
3. Does WKWebView + Webcrypto count?
What if I'm using WKWebView which contains access to webcrypto API https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API inside the app, does this count as "contain encryption"?
From Apple FAQ:
Use of encryption includes, but is not limited to:
Making calls over secure channels (i.e. HTTPS, SSL, and so on)
Using standard encryption algorithms
Using crypto functionality from other sources such as iOS or macOS
Using proprietary or non-standard encryption algorithms
You didn't specify source of your "exemption", but I guess it is not from Apple guidelines.
I would say that your cases are using encryption or crypto so are in scope of this guidelines.
I found some more informations here - maybe will help you.
We have developed a REST API which is consumed by two apps: one running on Android and one on iOS. The API is not public - we built the apps in-house.
Does it make sense to give a different consumer key to each different platform (e.g.: one for iOS on smartphone, one of iOS on tablets, one for Android on smartphones...)?
One advantage of having several keys is being able to easily do device segmentation analysis (however, that can be done in other ways).
Any strong point for one of the two strategies?
What are the advantages and disadvantages?
Thanks.
In the context of OAuth, any application that runs on an end-user device (including iOS and Android devices) is known as a "public" client because the secret key is distributed along with the application.
This is in contrast to a server-side web application, in which the key can safely remain secret. Only permitted developers and operations staff have access to it. In the case of applications that are distributed to devices, even with obfuscation, it's impossible to guarantee that the secret won't be exposed to unauthorized parties (essentially anyone with your app in their pocket), effectively rendering the key publicly available.
Given that, there is very little significance, from a security perspective, for assigning unique client IDs and secrets to devices that access your API. A malicious developer could very easily use the public credentials to pose as an "approved" app.
As you note, you can use a client ID to do device segmentation, but there are other ways to do that as well, such as a User-Agent header that don't convey misguided security implications.
In summary, there is no real benefit to issuing unique client IDs to apps based on platform. However, it is important to consider how public clients factor into the security concerns when authorizing access to your API.
If you will make app developers to use several OAuth consumer keys for each platform then developers will not be happy! Developers will have to somehow manage these keys to your service. What if app developers need to reissue the keys? If they launching app on new platform? How much additional effort of you these developers will need to maintain the keys?
Also, consider some platforms that you are not aware of: new mobile OSes, strange devices, unusual use cases. Do you want to limit and control all variants of uses of your service?
One of the reasons why you might still do that is that you can sell your API services separately for each platform (and probably with different prices).
I have an iOS application that uses certificates for messaging-signing following the Digital Signature Algorithm (DSA). In order to perform this signing, the app needs the certificate as well as the private key associated with the certificate. And, I cannot embed the certificate in the app as my customers need to be able to generate and distribute their own certificates to be used by the app whenever they need. (And, embedding a certificate would constitute a security risk anyway.)
Does anyone have any thoughts on how I might go about distributing the certificates and private keys?
PS. We do the same thing on BlackBerry and, there, we use BlackBerry Enterprise Server and APIs on the BlackBerry device to push certificates to the devices in the organization. I'm hoping there's a MDM solution to this for iOS but haven't been able to find anything yet.
Thanks much
You ask:
Does anyone have any thoughts on how I might go about distributing the certificates and private keys?
I'm sorry I don't know enough about your specific situation to tell you exactly how to meet your requirement, but I can tell that's not how it's usually done. Instead the public/private key pair is normally generated on the device, then the public key (only) is submitted with additional data (in a Certificate Signing Request, CSR, for example), to a server (Certification Authority, CA), which generates the certificate and returns it to the requester (and possibly publishes it in a directory).
An important security benefit to this approach is no third party has access to the private key (the CA needs the public key and doesn't need the private key). This is required for non-repudiation (so the device owner can't claim someone got his private key from the central server).
On iOS, there is no straight forward way to distribute a certificate and it's private key to an app. Apple suggests using PKCS12 and provides some guidance in this document: Technical Q&A QA1745: Making Certificates and Keys Available To Your App.