Payments is an industry ripe for disruption. Research suggests that anywhere between 30-50% of fintechs are developing payment technology. The reason for this is clear – payment networks are built on last century’s technology. A clean sheet design built on a modern stack will have many technological advantages.
However, as any investor knows, the challenge for a start-up isn’t the technology—it’s market need and industry readiness. In order for innovative payment technology to be widely adopted and succeed, the industry must overcome inertia and inch forward with security as a main priority.
Planning your security approach as you develop your payment apps? Here’s a starting point to guide your approach:
Six years ago, Apple added support for Bitcode with Xcode 7. Still, after all this time, there are many misconceptions about what it means for developers and their iOS apps. Here, we’ll discuss how “bitcode enabling” your app can affect its overall security.
What is Bitcode?
When a developer compiles code to upload into the AppStore, it must be converted from the human-readable source code to machine code. Bitcode is an Intermediate Representation (IR) of your code – somewhere between source code and machine code.
According to Apple, bitcode “allows the AppStore to compile your app optimized for the target devices and operating system versions, and may recompile it later to take advantage of specific hardware, software, or compiler changes.”
Essentially, this means that a bitcode enabled application can be optimized for the particular device it is being installed on. Not only that, but it will always be optimized with the latest and greatest compiler technology. Bitcode enabled applications guarantee that the end user will always have the best possible version of your app.
How Bitcode is Compiled
The compilers* built into Apple’s development environment, Xcode, take the source code and convert it to a format called LLVM IR. This step is performed by the compiler front end. Then, a compiler backend takes the LLVM IR and converts it into machine code—ready to execute on the device of choice.
For a bitcode enabled app, the LLVM IR is packaged with the application when it is published to the AppStore. The compiler backend is then executed by Apple as part of the AppStore infrastructure.
From a developer’s point of view, bitcode enabling an app is straightforward – it’s a single build option.
So why wouldn’t you take advantage of this targeted optimization offered by Apple? The answer is dependency chains – every component an app or framework consumes also needs to be bitcode enabled. If your app is integrating with older software libraries that aren’t bitcode enabled, you have two choices: You can either turn bitcode off or replace the libraries. Often, the easier option is simply to turn bitcode off. This is likely the reason Apple hasn’t yet mandated bitcode on all iOS apps.
However, bitcode is mandatory for tvOS and watchOS apps. Apple requires these to be published as bitcode enabled apps because the dependency chains of these newer operating systems have been fully bitcode enabled from day one. Unlike iOS, no migration is required for tvOS and watchOS apps.
Do You Trust Apple?
When it comes to security, the closer your code executes to hardware, the more difficult it is to reverse engineer. Thus, an intermediate format like bitcode is easier for an attacker to decipher and understand. For security’s sake, this is often a good reason to turn off bitcode.
However, it shouldn’t be a concern because bitcode is never installed on a device. In fact, it never even leaves Apple’s AppStore. As long as you trust Apple (and if you don’t, why are you publishing an app on their platform?) then bitcode should not be considered a security concern.
The Importance of Binary Integrity
Ensuring code executes exactly as the developer intends is key to its security. If an attacker can modify the code, it is easier to reverse engineer and easier to weaponize.
Anti-tamper technology checks the code to ensure it has not been modified. Enterprise-grade solutions will interweave a series of checks with your functional code. This creates a dynamic “check network” that constantly evaluates your code as it runs, making sure there are no differences between what is executing and what you intended.
Bitcode poses a challenge to anti-tamper technology since it enables Apple to change the executing code on a per device basis. The fact that the executing code can also change over time as Apple improve the compilers only adds to the security challenge. With the code changing, where does the anti-tamper get its reference picture so it can spot differences?
To solve this challenge and keep bitcode secure, Verimatrix launched Elastic Anti-Tamper technology. For the first time, bitcode enabled apps can be protected with enterprise-grade anti-tamper solutions. This adds to Verimatrix’s suite of proven Shielding products – giving our customers confidence in their iOS app security whether they bitcode enable their app or not.
*Clang for C, C++ and Objective-C, SwiftC for Swift
Nexoya Technologies is the partner of choice for many of the country’s leading bank, government organizations, enterprises, SMEs, and technology challengers. We help businesses elevate their value through custom Managed Services, IT & Business Consulting, Technology Solutions, Cybersecurity Training, and Full-Cycle Software & Mobile App Development. Nexoya Technologies is the authorized partner of Verimatrix.
