Secure Application Development

Shared Responsibility Model

Security is a shared responsibility between the SDK and the application. 

HID Global has made best effort to protect its SDK against analysis, reverse engineering and unauthorized code modification using various techniques. However, these protection do not cover the complete protection of the application itself which will interface with the SDK and manipulate sensitive assets.

Secure Coding Practices

Integrators should apply standard secure coding rules and guidelines to prevent introducing potential security vulnerabilities.

The Software Engineering Institute estimates that up to 90% of reported security incidents are the result of exploiting defects or vulnerabilities in the design or code of the software.  A relatively small number of common development errors (such as buffer-overflows, format-string attacks, or integer-overflows) may be easily identified, prevented, and eliminated by adhering to secure coding practices.

There are a number of secure coding guideline standards:

  • The MITRE Corporation’s Common Weakness Enumeration (CWE) list is a community-developed list of cataloging over 600 categories of software and hardware security weaknesses.  In particular, the CWE Top 25 is a commonly referenced list of the most widespread and critical weakness that can lead to serious vulnerabilities in software.  Many static analysis utilities leverage this list to identify potential weakness in code.
  • SEI CERT is another secure coding standard developed by Carnegie Mellon University and community effort by members of the software development and software security communities which targets commonly used programming languages such as C, C++, Java, Perl, and the Android platform. This common methodology targets insecure coding practices and undefined behaviors that lead to security risks.
  • The Open Web Application Security Project (OWASP) foundation provides a large number of documents, methodologies, resources, and tools to improve the security of software. In particular the OWASP secure coding practices guide and the OWASP mobile top ten critical security risks.
  • The National Institute of Standards and Technology (NIST) is a non-regulatory government agency that produces standards and guidelines for information and security practices such as for cryptography, authentication policies, as well as Federal Information Processing Standards (FIPS).

Binary Protection

It is recommended that integrators follow well-established standards such as the OWASP Mobile Security Testing Guide (MSTG) and OWASP Mobile Application Security Verification Standard (MASVS) which can help orient adding multi-layered protection such as code-hardening and Runtime Application Self Protection (RASP) against analysis, reverse engineering and unauthorized code modification using various techniques.  Generally, specialized third-party protection frameworks or libraries are used.

For example, some of these protection strategies may include:

Jailbreak/root, debugger, and emulator detection Code hardening/obfuscation Tamper detection
  • Blacklisting packages and binaries
  • Process forking checks
  • 'Test-keys' checks
  • Prevent debugger via ptrace
  • Debugger attached monitoring
  • Polymorphic obfuscation
  • Method inlining
  • Insertion of opaque predicates
  • Instruction substitution and instruction block chopping
  • Renaming controls
  • Shrinking, Name Obfuscation
  • Class encryption
  • Reflection
  • Sensitive String Encryption
  • Other Resource/Asset encryption
  • ASLR
  • Stack Smashing and Automatic reference counting
  • Verification of signature/encryption
  • plist checks
  • Anti-swizzling and hook detection strategies
  • Multilayer checksum checks

Code Protection Strategy

The integrating application should hence also apply a strategy to any vulnerable assets or sensitive calls to SDK entry points. The integrating application must identify which protection strategy to implement based on its risk profile, application design, SDK calls and manipulated assets.

For example, some of these assets might include:

asset application usage SDK entry point

password

password prompts

password change prompts

OTP

retrieveActionInfo

updateDeviceInfo

setStatus

retrieveTransactionIds

getOTP

changePassword

getChallenge

computeResponse

computeSignature

computeClientResponse

computeServerResponse

getAction

transactions

transaction information

transaction approval

setStatus

getAllowedStatuses

Transaction.toString

service activation

QR Code display

Manual activation fields

createContainer

renew