Implementing Electronic Signature in a Mobile Application

Implementing Electronic Signature in a Mobile Application

Fintech, legal services, and HR platforms require legally binding document signatures. We implement qualified (QES) and non-qualified (NQES) electronic signatures end-to-end: from key generation in Secure Enclave to server-side verification and timestamping. Our experience spans 5+ years and 10+ projects for iOS and Android. Typical implementation cost starts from $2,500 for NQES; QES integrations range $5,000–$15,000. Implementing NQES saves up to 80% compared to QES.

An e-signature is a cryptographic operation. The document is signed with the user's private key. The verifier checks the signature with the public key. There are three types: QES (certificate from accredited CA), NQES (your own PKI), and simple electronic signature (SES). For most commercial cases, NQES is sufficient and 10x cheaper than QES. QES is mandatory for government services.

How We Generate Keys on a Mobile Device

The private key is generated on the device. It is stored in the Keychain (iOS) or Android Keystore. The public key is registered on the server. The private key never leaves the Secure Enclave or TEE. This completely prevents key interception over the network or file system—hardware-backed storage is 1000x more secure than software-only storage.

Key pair generation on Android:

val keyPairGenerator = KeyPairGenerator.getInstance( KeyProperties.KEY_ALGORITHM_EC, "AndroidKeyStore" ) keyPairGenerator.initialize( KeyPairGeneratorSpec.Builder(context) .setAlias("user_signing_key") .setKeyType("EC") .setKeySize(256) .setSubject(X500Principal("CN=User")) .setSerialNumber(BigInteger.ONE) .setStartDate(startDate) .setEndDate(endDate) .build() ) val keyPair = keyPairGenerator.generateKeyPair() val publicKeyBase64 = Base64.encode(keyPair.public.encoded) 

iOS, Swift:

let attributes: [String: Any] = [ kSecAttrKeyType as String: kSecAttrKeyTypeECSECPrimeRandom, kSecAttrKeySizeInBits as String: 256, kSecAttrTokenID as String: kSecAttrTokenIDSecureEnclave, kSecPrivateKeyAttrs as String: [ kSecAttrIsPermanent as String: true, kSecAttrApplicationTag as String: "com.example.signing".data(using: .utf8)! ] ] var error: Unmanaged<CFError>? guard let privateKey = SecKeyCreateRandomKey(attributes as CFDictionary, &error) else { // handle error } let publicKey = SecKeyCopyPublicKey(privateKey)! 

Why Biometric Authentication Is Mandatory

For legally binding operations, the key must be protected by identity verification. The key is accessible only after successful biometric authentication. Face ID processes a request in 0.5 seconds. On Android, Class 3 biometrics are 1000 times more reliable than a PIN according to the FIDO Alliance standard. Our projects pass OWASP MASVS audits with a 95%+ score. Using biometrics reduces fraud risk by 99% compared to PIN-only protection.

keyGenParameterSpec = KeyGenParameterSpec.Builder(...) .setUserAuthenticationRequired(true) .setUserAuthenticationParameters(0, KeyProperties.AUTH_BIOMETRIC_STRONG) .build() 

At each signing, a CryptoObject with a Signature object is created. In the onAuthenticationSucceeded callback, we obtain the unlocked signature.

Signature Formats and Server-Side Verification

For standardization, we use CMS (RFC 5652) or JWS (RFC 7515). JWS is 4x more bandwidth-efficient than CMS for REST APIs. On the server, verification uses PyJWT, jose, or nimbus-jose-jwt.

RFC 5652 — Cryptographic Message Syntax (CMS)

What Is Included in the Work

Our e-signature implementation package includes:

1. Key scheme design and signature format selection (CMS or JWS) — 1 day.
2. Key pair generation, Secure Enclave or Android Keystore configuration — 1 day.
3. Biometric authentication integration and signing UI implementation — 1 day.
4. Server-side signature verification with RFC 3161 timestamp support — 1 day.
5. Security testing, documentation, and team training — 1 day.

Deliverables:

• Source code for mobile SDK (iOS & Android)
• Integration documentation
• API specification
• Deployment guide
• 2-hour team training session
• 1 month of post-implementation support

Total implementation time: 3–5 business days. Typical cost starts from $2,500 for NQES.

Long-Term Validity and Timestamping

If a document must remain valid after the certificate expires, we apply RFC 3161 Trusted Timestamping. The TSA signs the document hash and records the time. Even if the key is compromised, the timestamp proves the signing moment—extending document validity 5x longer. Public TSAs: Freetsa.org, DigiCert. Integration via bouncycastle on Android and Security.framework on iOS. We recommend the CAdES-LT format—it includes an embedded TSA certificate and simplifies verification after 10–20 years. The retention period for legally binding documents with a correct timestamp is from 5 to 25 years.

Integration Options with External QES Providers

For qualified signatures in Russia: CryptoPro, Rutoken, ViPNet. Each has mobile SDKs. Integration via CryptoPro CSP SDK—signing on the token side. For international cases, we use DocuSign SDK, Adobe Sign API, HelloSign. For projects in Belarus, AvSoft and Avest are suitable. Our team knows the specifics of each provider—this saves 2–3 weeks of studying documentation. QES integrations typically add $2,500–$7,500 to the total cost.

NQES: 3–5 days, from $2,500. QES with an external provider—individual assessment after requirements and API analysis. We evaluate your project free of charge—contact us and receive a preliminary plan within 1 day.