I need to make an app where you will open a PDF document, show it to a customer and he will electronically sign it(write his signature on a tablet).
From what I read you need the data from the signature being created (time stamp, pressure and time from drawing) and attach it to the PDF.
But is this enough? So to open a canvas, read the data and attach it to the PDF with the signature image itself or do I need to digitally sign the PDF as well? If this is it enough, then where to attach all that additional data(time stamp...)? - I plan on using itext library.
There are lots of aspects coming with your question. In the end it all comes down to your/your customers requirements of the process. Let me illustrate what you can do:
Firstly: There is a difference between a digital signature and a handwritten representation of a signature - although you can combine both...
Solution I
Capture the signature image (from a canvas), create an image out of it
Put the image into the PDF
Solution II
Same as above
Create a standard PDF signature field, set the signature-image as its appearance and digitally sign the field and thus the document (you need a certificate for that, but it can be self-signed). The timestamp (and further infos like location, reason etc.) can also be added and are part of the signature
Solution III
Same as above
Also collect the so called biometric data of the signature (x,y coordinates, pressure like you mentioned (however not always available) and timestamp for each coordinate pair
Encrypt the biometric data and add it to the signature field (strongly oversimplified)
Same as step 2 from above (cp. Solution II)
Solution IV (Update)
As you mentioned in your comment you want an eIDAS compliant signature:
"I do not need it to be digitally signed what I need is basic e-signature that is valid underneath eIDAS"
To make it clear: eIDAS is a way to digitally sign PDF documents.
Same as above
If you want an eIDAS compliant eSignature you also need a certificate. There is no way around it. But the certificate can be self-signed so it shouldn't be a problem. The rest is the same like in Solution II (step 2)
There may be other combinations (e.g. using qualified certificates from a smart card etc.) but in the end only you can decide what's the right solution for you. It depends on your requirements, your countries regulations and the legal necessities of the contracts you want to sign.
What are the differences of the solutions?
The first solution doesn't provide any possibility to verify the authenticity of the signer nor does it ensure that the document wasn't altered after the signature-image was added. Solution II provides exactly that however if self-signed certificates are used the signer cannot be identified (anybody could have signed that document). To prove that, you have to use qualified certificates or go with solution III.
Last remarks:
If the signer should sign at a certain place it makes sense to add empty signature field(s) when creating the document. Then when opened in your application a user can click on the signature field he wants to sign.
There are many existing solutions you could use exactly for that use case. Thus you also have to ask yourself: Why to reinvent the wheel?
Most of those solutions also don't directly sign the document on the (android) client but do the actual signing on a central server. Using that approach you don't need to re-implement you solution for each platform (iOS, windows phone, Webbrowser on a desktop pc etc.)
Related
What I want to know is can a signed apk be extracted and edited? And can the attacker again compress the apk and attack a victim?
I know that we can use proguard to obscure the code but some people said that the apk still can be extracted and modified through reverse engineering.
My main concern is I want to encrypt my java files because I have some authentication data in my java files.
Can anyone give me a bulletproof method to protect java files from being inaccessible.
Edit -
Found few old thread in stack but they never explained about signed apk and protect them from getting exploited.
Yes. Cryptographic signing is not encryption. Signing proves that whoever signed it knew a secret key. Assuming the key is kept secure, you can be sure that two files signed by the same key are from the same person. With some forms of signing with public and private keys, it can be used to prove the identity of the signer. This does not provide any protection against reading that data, although it does provide protection against a counterfeit copy of the app being claimed as the real thing (assuming the user pays attention to the signature).
There is no way to do what you want to do. In the end, an app has to be run by a processor or interpreter. That means it needs to be translated into instructions that the processor understands. If you want something to be secure, do not put it on a client device. There is no way to protect it if you're sending it to a device that needs to decrypt it and use it.
Any APK can be decompressed and have its sources read. You cannot, however, edit it and sign it without the signing key.
There is no way to encrypt your source files and everything inside of them is readable by anyone. Authentication data shouldn't be stored in an application if it is expected to be secret.
signed apks can easily be reverse engineered. You should never place authentication data in the source code. There is no bullet proof solution for this. However you can make it difficult for the attacker by encoding and not placing your critical data in obvious places.
You should use another way to use your authentication data, I've read something about building a binary and storing inside the lib directory as a .so file, I'm not sure how exactly it's the proccess because I didn't tried, but you can research another methods, storing private data on Java source it's not secure.
I have to implement in an Android application a function that allow me to sign a PDF, when i say "sign" I mean the digital signature (First and second name) affixed to the end of the document from the user.
I have access to a Samsung Note 4 (with stylus) then it would not be a problem, "write" on the display.
The question is: there is the possibility to sign a document using some library like itext or I must write a custom function ?
I guess you want to apply an electronic signature on a document using a user's handwriting with a pen. As has said #mkl, 'digital signature' concept is usually applied when using digital certificates and cryptography.
Handwritten electronic signature requirements
People tend to think that the handwritten signature consists of embedding an image, but so that your system has a minimum legal value in case of litigation you will need:
R1 - ensure the identity of the signer
R2 - Uniquely attach signature and document
R3 - protect integrity of document and signature
More or less these are the characteristics of digital signatures.
Handwritten signature on Android
The process on android should be like this:
R2) capture the user graph including biometrics(x,y,time,pressure) using a Canvas. Embed image and biometrics data into document using PDFBox or itext (client or server side)
R1) included biometric data in previous step allows a potential analysis of signature by an expert
R3) I suggest to apply a timestamp over document and signature evidences to protect the integrity and ensure the time of signature. Both itext and PDFBox support it
If you do not need legal value, then apply only the drawing part. The quality of your signature will be determined by the devices characteristics. For example a specific signature tablet can provide also the orientation of the pen
Android links
Drawing on Canvas and save image (see example, you can get pressure and time from event)
PDFBox, inserting image in pdf
PDFBox attach files to pdf
PDFBox digital-signature example with timestamp
You will find similar links for itext. Select the most suitable for your use case and whether you want to execute on Android or in the server side
MD5 fingerprint of any app can be easily acquired using keytool. Then what is the most unique identifier an app has?
I am trying to build a client server app and I want a secure the communications.
My problem revolves around these two assumptions -
1) Someone can reverse engineer my app and understand how I interact with server webservices
2) My app can be simply uninstalled and replaced with malicious app with similar package name.
The system can easily compromised using these two loopholes.
My solution to these problems was transmitting MD5 signature of my app to the server. The MD5 signature will be conveyed to server before hand. MD5 signature is unique for every app, But there is big problem in this approach. MD5 signature of any apk can be generated using keytool. Anyone may pull my apk and generate MD5 and use it in the webservices communication.
What is the unique identifier of an android app?
Package name and MD5 fingerprint can be easily compromised!
Basically you want to be sure that you are talking to your client app at server end.
Verify Back-End Calls from Android. This link could be helpful as it gives high confidence for such a case. (HTTPS is must here)
As an additional step for #Maddy 's answer, you might think about tamper resistance/integrity protection techniques, that will make your app inoperable in case somebody tried to modify it. DexProtector (http://dexprotector.com) could be the solution here. The slides under the link also should be helpful.
N.B.
I am Licel's CEO, thus I am affiliated with DexProtector.
First question
1) My app can be simply uninstalled and replaced with malicious app with similar package name.
best approach is probably the use of ANDROID_ID
Try this link http://blog.vogella.com/2011/04/11/android-unique-identifier/
Check this also http://android-developers.blogspot.in/2011/03/identifying-app-installations.html
Solution for the second issue
2) Someone can reverse engineer my app and understand how I interact with server webservices
Use DexGuard, which can make reverse engineering even harder, like by encrypting strings
https://www.saikoa.com/dexguard
Proguard
“The ProGuard tool shrinks, optimizes, and obfuscates your code by removing unused code and renaming classes, fields, and methods with semantically obscure names. The result is a smaller sized .apk file that is more difficult to reverse engineer.”
When you create android project.
1. proguard.cfg file is automatically generated in the root directory of the project.
2. The default configuration file only covers general cases, so customize as per your needs.
Enable it
“Set the proguard.config property in the /project.properties file. The path can be an absolute path or a path relative to the project’s root.”
Case1: Just add proguard.config=proguard.cfg if the proguard.cfg is in projects root path.
Case2: Configure from other location [proguard.config=/path/to/proguard.cfg]
Remove the “#” (or uncomment) the proguard configuring statement in project.properties. Which will be in commented initially.
Customize it. try this link http://1belong2jesus.wordpress.com/
I am developing an application that has SQLite database to store personal information that must be protected. What are some ways of protecting these personal data? An APK can easily be de-compiled completely, so how can we secure an APK? Additionally, how can a database of a mobile application be protected?
Basically, there are 5 methods to protect your APK being cracking/ reversing/ repackaging:
1. Isolate Java Program
The easiest way is to make users unable to access to the Java Class program. This is the most fundamental way, and it has a variety of specific ways to achieve this. For example, developers can place the key Java Class on the server, clients acquire services by access relevant interfaces of the server rather than access to the Class file directly. So there is no way for hackers to decompile Class files. Currently, there are more and more standards and protocols services provided through interfaces, such as HTTP, Web Service, RPC, etc. But there are lots of applications are not suitable for this protection. For example, Java programs in stand-alone programs are unable to isolate.
2. Encrypt Class Files
To prevent Class files from being decompiled directly, many developers will encrypt some key Class files, such as registration number, serial number management and other related classes. Before using these encrypted classes, the program needs to decrypt these classes first, then loading these classes into JVM. These classes can be decrypted by hardware, or software.
Developers often loading cryptographic classes through a customed ClassLoader class (Applet does not support customed ClassLoader because of security). Customed ClassLoader will find cryptographic classes first, then decrypt them. And finally loading the decrypted classes to JVM. Customed ClassLoader is a very important class in this protect method. Because it itself is not encrypted, it may be the first target of a hacker. If the relevant decryption key and algorithm have been overcome, then the encrypted classes can easily be decrypted.
3. Convert to Native Codes
Convert program to native codes is also an effective way to prevent decompilation. Because native codes are often difficult to be decompiled. Developers can convert the entire application to native codes, or they can also convert only key modules. If just convert key part of the modules, it will need JNI technology to call when Java programs are using these modules. It abandoned Java's cross-platform feature when using this mothod to protect Java programs. For different platforms, we need to maintain different versions of the native codes, which will increase software support and maintenance workload. But for some key modules, sometimes this solution is often necessary. In order to guarantee these native codes will not be modified or replaced, developers often need to digitally sign these codes. Before using these native codes, developers often need to authenticate these local codes to ensure that these codes have not changed by hackers. If the signature check is passed, then developers can call relevant JNI methods.
4. Code Obfuscation
Code obfuscation is to re-organize and process Class file, making the treated codes accomplish the same function (semantics) with the untreated codes. But the obfuscated codes are difficult to be decompiled, i.e., the decompiled codes are very difficult to understand, therefore decompile staffs are hard to understand the really semantics. Theoretically, if hackers have enough time, obfuscated codes may still be cracked. Even some people are developing de-obfuscate tool. But from the actual situation, since the diversified development of obfuscation, the mature of obfuscation theory, obfuscated Java codes can well prevent decompilation.
5. Online Encryption
APK Protect was an online encryption website for APK, but activity has apparently been discontinued since 2013 or so. It provided Java codes and C++ codes protection to achieve anti-debugging and decompile effects.
I originally suggested you use this last method for it could save you more time. Based on my experience, it was very simple to operate and it wouldn't take long time.
With Jellybean this has now become a possibility.
$ openssl enc -aes-128-cbc -K 000102030405060708090A0B0C0D0E0F
-iv 000102030405060708090A0B0C0D0E0F -in my-app.apk -out my-app-enc.apk
$ adb install --algo 'AES/CBC/PKCS5Padding' --key 000102030405060708090A0B0C0D0E0F
--iv 000102030405060708090A0B0C0D0E0F my-app-enc.apk
pkg: /data/local/tmp/my-app-enc.apk
Success
Please read the following blog post for further details
If this is secret information that must not fall into the hands of your users, you cannot secure it. It is fundamentally impossible to put information on a device (code or data), and have your application access it, but not allow someone with the device to have access to that information.
Encrypting the information is pointless from a security point of view, because your application has to contain whatever is needed to decrypt it in order to use it, and a sufficiently motivated attacker can always extract that and decrypt it on their own.
All you can do is make it more annoying and time consuming to get access to that information, which only helps if there's not really that much of a need to keep it secret. This is what using proguard to obfuscate your .apk file can do.
Have you considered sqlite encryption? See this thread - sqlite encryption for android
As for protecting your .apk, try obfuscating your code using proguard. See http://developer.android.com/guide/developing/tools/proguard.html
You can try 'Anti Decompiler(Android)Trial'
https://play.google.com/store/apps/details?id=com.tth.AntilDecompilerTrial
It makes something Proguard doesn't:
Hide all const values (string, character), you will never see clear text like "my key", "my val"... in your apk file
Obfuscate file name, which is referenced in AndroidManifest.xml
Add fake code to your source code. Event the powerful decompilers likes: dex2jar, jd-gui,... can't reverse exactly your apk file. Most of functions will show with comment 'Error'.
=====
After transforming, if you give someone your source project, it will be nearly impossible to read and understand.
This solution doesn't exclude Proguard, You can combine them together. (function, field Obfuscation of Proguard is better than Obfuscation features of this solution)
You may read my post at: http://www.androidpit.com/en/android/forum/thread/567093/An-Analysis-of-Android-APK-Protect-Shell-APKProtect. The APK added with protect shell of APK Protect is seems unable decompile. I mean, the encrypt method is very advanced. Even a master hacker need long time to crack it.
If it is the database that contains sensitive data you can encrypt the values of several columns or the full database like mentioned in the other answer and make sure that the password is not stored on the device but has to be entered by the user on accessing the data.
If there are pieces of code you need to protect there's really no good way of securing it. All you can for a limited amount of use-cases is to create a dependency to an online service and secure the server. But for a lot of applications this would not be an option.
First, make apk that can never be modified and used. I do it by temper detection from the server. I use root check emulator check. Then on the important activity, it checks root and emulator on every oncreate and on resume, deletes important data on onpause, Great. Now encrypt data and place license to server, use SSL server. It app can not be modified and run, everything is safe for ever. Well, how to avoid decompiler and online tamper detection. I do placing a huge code to generate some sample string from apk file, and compare it with an apk copy placed on the server. I have converted apk file to string. Just enjoy.
We've been asked to create a thin web client on Android for a company with an existing web site, existing users.
They want to send an mms to their users, giving each user their own download URL. This URL will point to an Android apk file that has been created specifically for that user - it will include that user's login, and password, to the website.
i.e. the APK file would have embedded login details.
This would be done in J2ME by storing info in the JDK file.
I can see a simlar question on How to update resources file in apk - but not fully answered.
So:
is there a way to store an "asset" in the apk file that will be a text file, and easily editable by unzipping, editing, rezipping the apk file? (looks like answer is no)
do you know of any similar problems, or have worked on similar apps?
is there advice on how best to accomplish this application? Any sort of embedding of customer info on an automated level would be of interest...
would the best option be to set the app to build with an Ant script, and have the client actually customize the source code and build a new app per user? (this has the con that the client gets the source code, which we'd rather not have)
I have scanned apk tagged questions and can't seem to find a solution to this.
Many thanks,
Richard
I guess you could put it into the apk (or replace a dummy file there) if you use the assets folder for it.
You can obtain the data by filename instead resource-id quite easy:
getResources().getAssets().open(fileName)
Regards,
Oliver
If it absolutely has to be that way, consider distributing two APKs, one with the application and the other containing a file with the handset-specific information. Sign them both with the same key, arrange for them to share a UID and the application will be able to read the file as if it were its own.
The rest of this probably belongs in a comment and not this answer, but I see lots of problems with what you're being asked to do:
The standard behavior for just about every other application out there is to ask for a login and password once when needed and then remember it.
If the user changes his password on your customer's web site, he has to get a new APK for his device instead of just having to reauthenticate.
Any changes to the application will require generation and installation of a new APK for each user.
All it would take is some unwitting user sharing his unique APK with someone else and your whole security model goes right down the tubes.
Less relevant, but still important: If your customer is able to reconstitute a plaintext password from what they have stored, I question their security scheme.