The Need for Secure eHealth Apps

eHealth apps – your daily companion

In the healthcare sector, too, the range of apps has risen rapidly in recent years. Effectively, they have become everyday companions at work and at home. Already in 2017 roughly 325,000 mobile health apps were counted in app stores, and in 2018 a whopping 400 million of those apps have been downloaded. All those apps measure our fitness, give health tips, analyze physiological data, measure vital signs or calculate the dosage of medications.

More users come along with higher risk of data breaches and higher attractiveness for fraud

Connected health devices and wearables, such as glucometers and cardiac monitors, also collect a treasure trove of data from millions of people every day. Unfortunately, they are often unsecured and open to hacking, potentially exposing patients to adverse effects on their health. Healthccare providers and insurers must expect considerable legal, financial and operational consequences. Health insurance companies are modernizing their approach, providing digital access to insurance cards and medical records. The data breach risks associated with these are, of course, a major concern that needs to be addressed from the outset.

All companies in the fields of medicine and health insurance are faced with the challenge of providing top medical services. Digital services for patients are now being added, which on the one hand must comply with the strictest security and data protection regulations and be resistant to cyber attacks, which can be both costly to mitigate and dangerous for patients. The stakes are higher here than in almost any other field – it really is a matter of life and death in some cases.

Threats to your digitization efforts

The main threats arising from the digitalization of the healthcare industry are fraud, privacy and HIPPA (USA)/GDPR (EU) violations, ransomware and cyberattacks, unauthorized data collection, and hacking of connected medical devices and mobile phone applications. The only way to combat such threats is by implementing adequate security measures right from the very start. In particular, in app development, this means incorporating security measures during the develophment phase and not retrofitting security at the end.

Medical and health insurance professionals can meet this challenge by making online security a priority. Investing the time and resources required to protecting digital channels could prove invaluable on many levels, saving lives and preventing significant financial losses in the future. Since most health information is being digitalized for optimal mobile use, app security is at the forefront of this. Online security depends on being able to verify the identity of the patient and making sure that they are the only ones who are accessing their health information.

Call for action: Protect your eHealth app from growing risks and threats

It is Build38’s strong believe that in a changing digital landscape, app security isn’t a luxury. It is a necessity. Your developers should focus on what they are best at: delivering business value and world-class eHealth apps, while Build38 provides mobile app security. Build38’s Trusted Application Kit is a highly secure, holistic and easy to integrate mobile app security framework.

For the eHealth field, all this means that app users and service providers can rest easy in the knowledge that their highly sensitive data is safe. Patients can use the available digital services in comfort and ease, while medical professionals and insurers can be confident that the risks commonly associated with such services, such as fraud and cloning, are prevented.

In detail: how we can help

Build38’s approach to mobile app security is based on a unique triple-protection approach for compromise detection and continuous hardening: ensuring the integrity of device, app and security.
The SDK and cloud can detect changes to the device’ secure execution environment, and in case of compromise or an ongoing attack, it can render its own function useless immediately. At the same time the app is secured by various In-App protection mechanisms, and while in use it is protected by RASP-technology (Runtime Application Self Protection). The protected data is never visible in clear nor can it be extracted from the device at runtime. When the same data is in motion the Secure Channel and Certificate Pinning prevent Man-in-the-middle (MITM) attacks.

For more detailed information on Build38’s mobile app security please read our whitepaper “Digitalisierung im Gesundheitswesen und Gefahren durch unsichere Apps" (in German) or the same whitepaper in English "Hacking Healthcare - why unsecure apps are bad for patients and providers".


Security through obscurity: why not?

Wired magazine recently published an article with the following statement:

Think of shielding code like hiding a safe behind a painting. If you have a secure enough lock, it shouldn't matter who can see it.

Well… I have to say that I (somehow) disagree. As with everything in life, the right wording is “it depends”. In this case, it depends on the execution environment.

But let’s back up for a moment. What is app shielding? OWASP, a global non-profit organisation focused on improving the security of software, describes app shielding as “a set of technologies that typically modify an application’s binary code to make it more resistant to reverse-engineering, tampering, invasive monitoring and intrusion.”

Which kind of relates to a broader topic known as "security through obscurity". From Wikipedia: "Security through obscurity (or security by obscurity) is the reliance in security engineering on design or implementation secrecy as the main method of providing security to a system or component. Security experts have rejected this view as far back as 1851, and advise that obscurity should never be the only security mechanism."

[Spoiler alert] The right answer is in the last sentence: "[…] should never be the only security mechanism."

An analogy

Let’s try to find a more specific scenario. The example of the safe proposed in Wired’s article is a good analogy of a cryptographic protocol: the safe would be the protocol itself, the safe’s key (eitherphysical or a passcode) would be the cryptographic key, and the content of the safe would be the data to be protected with encryption. In both cases, the security of the system relies on the assumption that the key is kept in a safe place. But what if this is not possible? What if we had to store the key close to the safe?

This is exactly what happens in mobile apps. If we want to use cryptography (and we need to), we also need to store the keys somewhere in the smartphone so we can use them. Even if we use the latest cryptographic engines (available only in new, high-end devices; such as the hardware-backed KeyStore in Android or the Secure Enclave in iOS), this only solves the problem for a fraction of our user base – and that’s not good enough.

So, what do we do? We hide the safe behind a painting. And we hide the key behind a different painting. Additionally, we implement as many mechanisms as possible, in order to make it very time consuming for a thief to find both the key and the safe - so much time consuming, that the police will be there before he can find both of them.

Can you see the analogy? This is the goal of app shielding: we put as many hurdles as possible in order to force the hacker to spend a lot of time finding the key and knowing how to use it. So much time that we have time to react. And "react" means, for example, that we crash the app process (which makes it very difficult to keep searching), or we delete the user data (emptying the safe, in case it is ever open), or we even change the key itself (frustrating an otherwise successful search).

Mobile Apps need more than just App Shielding!

Of course, app shielding on its own is not enough: we need well-known and tested primitives and protocols behind. But this is also true the other way around: if we don’t protect the key it doesn’t matter which protocol we use.

At Build38, our Trusted Application Kit (T.A.K) uses all sorts of app shielding techniques to protect our customer’s assets – that’s also the reason why we like to call it In-App protection:

  • Our in-house compiler obfuscates T.A.K’s binary code, making static analysis a lot harder.
  • With whitebox cryptography we make sure that cryptographic keys are never in plain in memory (not even while they are being used at runtime!).
  • With certain runtime checks such as root/jailbreak, emulator, debugger or app re-packaging, we prevent dynamic analysis.
  • Finally, on top of pure in-app protections, Build38 uses a cloud platform that monitors the app to identify app and code modifications. The platform allows integration into SOC, SIEM and analytic systems.

All of this together allows us to provide the most comprehensive set of security features, which in turn enables app developers to focus on writing amazing apps , no matter the smartphone they are deployed on.


The impact of PSD2 on your financial app

PSD2 and what it means to your company

2019 is set to be a game-changing year for retail banking and FinTechs! As the PSD2 (Revised Payment Service Directive) becomes implemented and finally enforced on 14 September 2019, banks’ monopoly on their customer’s account information and payment services is becoming history.
In short, PSD2 enables both consumers and businesses, to use third-party providers to manage their finances. Soon you may be using your favorite social network to pay your bills, making peer-to-peer transfers and analyze your spending, while still having your money safely placed in your current bank account. PSD2 will fundamentally change the payments value chain and customer expectations.
Through PSD2, the European Commission aims to improve innovation, reinforce consumer protection and improve the security of internet payments and account access across the EU.

PSD2 and its implications on mobile security

The PSD2 guidelines set security requirements for payment services providers across the EU and will provide enhanced protection of EU consumers against payment fraud on the Internet. Specifically, the PSD2 security requirements for mobile apps are referred to in the Regulatory Technical Standards (RTS), for example, paragraph 26 and articles 9, 27 and 28.
RTS requires that the mobile app is running in a secure environment. This means that the integrity of the mobile device should be guaranteed and in case of compromise mitigation measures are taken. The same integrity and mitigation principles apply for the mobile app, too. Risk mitigation measures include the destruction, deactivation and revocation of the service. PSD2 also has a strong focus on data protection: data (e.g. certificates) shall be protected at rest, and when data flows between the mobile app and the service provider, the mobile apps should ensure the security of communication sessions and should avoid misdirection of communication.

Build38 makes your digital mobile channel PSD2 compliant
Your developers should focus on what they are best at: delivering business value, while Build38 provides mobile app security. Build38’s Trusted Application Kit (T.A.K) is a highly secure, holistic and easy to integrate mobile app security framework. It enables you to deliver PSD2 compliant mobile apps.
Build38’s approach to mobile app security is based on a unique triple-protection approach for compromise detection and continuous hardening: ensuring the integrity of device, app and security.
T.A.K can detect changes to the device’ secure execution environment, and in case of compromise or an ongoing attack, it can render its own function useless immediately. At the same time the app is secured by various In-App protection mechanisms, and while in use it is protected by RASP-technology (Runtime Application Self Protection). T.A.K protected data is never visible in clear nor can it be extracted from the device at runtime. When the same data is in motion the Secure Channel and Certificate Pinning prevent Man-in-the-middle (MITM) attacks.
It is Build38’s strong belief that in a changing digital landscape, app security isn’t a luxury. It is a necessity.
For more detailed information on Build38’s mobile app security please have a look at our whitepaper.


Build38 Recognized in Gartner 2019 Market Guide for In-App Protection

Munich, Germany, July 5, 2019 – Build38 GmbH, leading vendor of In-App protection and enabler of passwordless authentication solutions has been recognized as Representative Vendor in the Gartner July 2019 “Market Guide for In-App Protection” report. Gartner states, that “by 2022 at least 50% of successful attacks against clickjacking and mobile apps could have been prevented by using in-app protection.”

Build38’s Trusted Application Kit (T.A.K) secured mobile apps diagnose and protect themselves at runtime with Build38’s next generation RASP technology. T.A.K delivers valuable insights to service providers so that they can react on upcoming threats and fraud in real-time. To the end-user of your apps T.A.K remains invisible and non-intrusive, yet it gives your users a high level of trust and security.

T.A.K is a platform solution and an SDK for Android and iOS that allows a quick and easy development of highly secured and protected mobile apps. It is integrated into mobile apps within hours, therewith saves development costs and shortens the crucial time to launch the mobile app.

The Trusted Application Kit (T.A.K) is used globally and deployed by financial institutions, enterprise services, insurance companies, and the automotive industry.

Gartner recommendations is that “security and risk management leaders responsible for application security choose in-app protection for critical and high-value applications that run within untrusted environments and move software logic on the front end. The most common use cases will be mobile apps, single-page web apps (especially consumer-facing ones) and software on connected devices.”

“We hear almost daily that mobile apps need by far better protection than most people are aware of. We believe that Build38 helps customers to propel your app security to a new level of operational excellence. We believe this report acknowledges that In-App protection (application shielding) is a necessity to fight the growing numbers of attacks and fraud cases. We know that App security is not a luxury anymore, it is a must!” says Build38 CEO Dr. Christian Schlaeger. “We are convinced that our Trusted Application Kit, included in this Market Guide report is the most holistic solution in the market. We believe it provides a broad range of In-App protection features for the app and delivers risk- and fraud detection and prevention information to the service provider”.

 

Gartner subscribers may access the report here: https://www.gartner.com/document/3947048

Gartner, Inc., "Market Guide for In-App Protection" by Dionisio Zumerle, Manjunath Bhat, 3 July 2019.

Disclaimer: Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner's research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.

 

About Build38

Build38 is a global provider of mobile application protection solutions. Its Trusted Application Kit (T.A.K) represents a new generation of app-hardening technologies that protects apps from known and unknown attacks and opens the market to new digital business models. Build38 protects applications across various industries including automotive, financial, public transport and health care. Build38 is headquartered in Munich with global offices in Barcelona and Singapore. The company is a spin out of Giesecke + Devrient and ranks among the best IT Security startups in Germany. For further information about Build38 visit www.build38.com.

 

 


Lessons from Japan: Preventing Account Takeover through App Security

Recently, it has appeared on the news that one of the largest convenience store chains in Japan, that uses a mobile wallet in order to perform payments associated to a credit card, has suffered an attack that ended up in the total loss of 55 Million Yen by almost 1,000 users. Based on public information, it is believed the attack was based on an account takeover scheme. The attacker started a password recovery process that ended up in sending an email with a password reset link.

Apparently, the process was implemented in a way that the user had the option to send the reset link to an alternative email address than the one that was originally used to sign for the account. This is a very strange practice as generally when resetting your password you use some element as the original root-of-trust (the original email address) but in this case it seems that they were using some very basic information like birth date as the root-of-trust.

Even if there is no evidence that the Mobile App was compromised and if additional countermeasures would have prevented the attack, the question here is: Can we design a password reset mechanism that can overcome the flaws of current methods? Beside this particular news, we have heard of many cases of account takeovers by attackers using SIM Card replacement mechanisms, where the Service Provider has to rely on the Mobile Network Operator / Carrier of the user to do the right verification before providing a SIM Card replacement.

Solving the issue: What if the Service Provider didn’t have to rely on third parties for that?

That brings us to an improved flow for the password recovery mechanism. Imagine you have a Mobile Wallet that you use to make purchases and you have a Mobile App in your phone, protected by some kind of user verification, e.g. Fingerprint or FaceID. One day, you want to access your account from a website. Or you are asked to login again and you forgot your account password. In a current scenario, the user would request a password reset and a link would be sent to their Email that once clicked would be used to set a new password. An alternative would be an SMS to their phone number with the link or a code for the password reset.

In the improved scenario, the Mobile App on the phone is strongly linked to it. This means that it can’t be copied to a different phone, the keys stored can’t be compromised or the communication sniffed. We also don’t have any need to rely on an SMS, whose phone number may have been compromised by poor carrier KYC mechanisms to get a SIM Replacement, or Emails that may be have compromised in multiple ways. This would work as follows: I want to login through the website but I can’t remember my password. I click on recover password. The user is asked through the website to open their app on the phone, do user verification, e.g. Fingerprint, and once is verified the possibility to define a new password is shown on the website. In the case of someone trying to take over the account, once they request the reset password link they will not get through as the real user is not going to open the app and accept the reset of the account.

Actually, such a flow would go in the direction of the Payments Japan Association guidelines that "requires the operators of mobile payment services to confirm the linkage between the devices of users and apps downloaded on them to prevent unauthorized access."

In the case that the user forgets the password and loses access to their phone at the same time, a specific “Red” path for the user verification shall be established. The good thing is that in this scenario, if an attacker is pretending to have lost their phone and forgot the password of the user, the actual user could be alerted of this happening though a warning to the App on the legit mobile device, being able to inform the Service Provider that they have not initiated such a process and alerting the Service Provider that an attack is happening.

Thus, using a strong device binding and a hardened app we can solve many of the risks associated with online account takeovers. Build38, through its family of technologies under the Trusted Application Kit (T.A.K) is able to make Service Providers independent of security processes of others, e.g. Mobile Network Operators / Carriers, Email and ISP providers. Contact us to learn more about Build38 and how we can help you transform your Mobile Security!

#buildonBuild38

 

Image by TheDigitalWay from Pixabay