I built a couple of test IoT hardware devices for home automation which I want to control with an Android app I also wrote.
The app will be used by several people.
My plan is to use Amazon IoT Core to let the apps send MQTT commands to the IoT devices.
Since my hardware devices are not very powerful (ESP8266 architecture) I'm going to authenticate via the Signature Version 4 (SigV4) scheme. This auth scheme is useful when the hardware device is not powerful enough to authenticate via the standard privatekey/certificate method; it requires a pair of key/secret IAM credentials to be hardcoded into the device firmware (instead of the certificate and private key).
I then created a test "thing" in the IoT Core console and I can successfully send commands from the apps to the devices (and receive data from the devices and show them on the apps).
My question is, do I need to create as many "things" as the IoT devices? Since each device will have its own IAM credentials, can I just use one shared "thing" for all the IoT devices?
I can't find any best practice online, not even on the official documentation.
The short answer is, don't go there.
A thing is a logical entity in AWS.
The reason to use many things is that you can:
Group them
Create a certificate for each one (with policies)
Use the shadow to manage the thing state
Search them
While you can do what you are saying, using IAM for things is not what AWS had in mind. IAM is supposed to be used by humans. You could use strong names and passwords, but you find it difficult to manage, and you hit the 5000 policies limit pretty quickly.
You can give all your device the same username and password, but then how would you revoke a single one when needed.
I'm not a hardware expert but if you really can't use certificates then you don't really need things but do have a look at AWS STS that will let you create temp credentials for your device.
You'll have to manage the login process somehow (not using AWS) and then generate an access key and secret key for each device.
I have a website that store private information that can be accessed by request with a secret api key.
My Android application have to access that private information, and to do that it use a proxy server that store and use the secret api key to communicate with the website
The problem is that just using Wireshark, or finding the string in the app resources file, someone can see the proxy server url and use it to get the private data from the website
How can i make this system secure? how can i be sure that none else can use the proxy except the Android app?
Thank you!
I have a website that store private information that can be accessed by request with a secret api key.
From the moment you put a secret on the client is not anymore a secret, because now is public and anyone can see it by reverse engineer the app or by intercepting the traffic with a proxy or by just watching the traffic with the tool you mention, Wireshark.
My Android application have to access that private information, and to do that it use a proxy server that store and use the secret api key to communicate with the website
Using a proxy server doesn't solve the problem, because the proxy server doesn't know WHAT is calling it. As it stands the proxy server is open to the public that knows how to call it, as you already know and pointed out:
The problem is that just using Wireshark, or finding the string in the app resources file, someone can see the proxy server url and use it to get the private data from the website.
Another approach is to use a proxy tool like the MiTM Proxy that in my opinion will allow to extract more easily the API key, as you can see in the article Steal that API Key with a Man in the Middle Attack:
While we can use advanced techniques, like JNI/NDK, to hide the API key in the mobile app code, it will not impede someone from performing a MitM attack in order to steal the API key. In fact a MitM attack is easy to the point that it can even be achieved by non developers.
ADDRESSING YOUR QUESTIONS
How can i make this system secure? how can i be sure that none else can use the proxy except the Android app?
Well you bought yourself a very hard problem to solve, that a lot will say that is only possible to make it harder to be solved by the attacker, and this is true until some degree, because a lot of developers are not aware of the Mobile App Attestation concept, that allows a back-end server to only server requests comming from a original app.
Before I can explain you the concept I would like to clarify a common misconception among developers regarding the WHO vs WHAT is accessing your back-end server.
The Difference Between WHO and WHAT is Accessing the API Server
To better understand the differences between the WHO and the WHAT are accessing an API server, let’s use this picture:
The Intended Communication Channel represents the mobile app being used as you expected, by a legit user without any malicious intentions, using an untampered version of the mobile app, and communicating directly with the API server without being man in the middle attacked.
The actual channel may represent several different scenarios, like a legit user with malicious intentions that may be using a repackaged version of the mobile app, a hacker using the genuine version of the mobile app, while man in the middle attacking it, to understand how the communication between the mobile app and the API server is being done in order to be able to automate attacks against your API. Many other scenarios are possible, but we will not enumerate each one here.
I hope that by now you may already have a clue why the WHO and the WHAT are not the same, but if not it will become clear in a moment.
The WHO is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.
OAUTH
Generally, OAuth provides to clients a "secure delegated access" to server resources on behalf of a resource owner. It specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials. Designed specifically to work with Hypertext Transfer Protocol (HTTP), OAuth essentially allows access tokens to be issued to third-party clients by an authorization server, with the approval of the resource owner. The third party then uses the access token to access the protected resources hosted by the resource server.
OpenID Connect
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
While user authentication may let the API server know WHO is using the API, it cannot guarantee that the requests have originated from WHAT you expect, the original version of the mobile app.
Now we need a way to identify WHAT is calling the API server, and here things become more tricky than most developers may think. The WHAT is the thing making the request to the API server. Is it really a genuine instance of the mobile app, or is a bot, an automated script or an attacker manually poking around with the API server, using a tool like Postman?
For your surprise you may end up discovering that It can be one of the legit users using a repackaged version of the mobile app or an automated script that is trying to gamify and take advantage of the service provided by the application.
Well, to identify the WHAT, developers tend to resort to an API key that usually they hard-code in the code of their mobile app. Some developers go the extra mile and compute the key at run-time in the mobile app, thus it becomes a runtime secret as opposed to the former approach when a static secret is embedded in the code.
The above write-up was extracted from an article I wrote, entitled WHY DOES YOUR MOBILE APP NEED AN API KEY?, and that you can read in full here, that is the first article in a series of articles about API keys.
First question
How can i make this system secure?
Depending on your budget and resources you may employ an array of different approaches and techniques to defend your API server, and I will start to enumerate some of the most usual ones, but before I do it so I would like to leave this note:
As a best practice a mobile app or a web app should only communicate with an API server that is under your control and any access to third party APIs services must be done by this same API server you control. This way you limit the attack surface to only one place, where you will employ as many layers of defense as what you are protecting is worth.
You can start with reCaptcha V3, followed by Web Application Firewall(WAF) and finally if you can afford it a User Behavior Analytics(UBA) solution.
Google reCAPTCHA V3:
reCAPTCHA is a free service that protects your website from spam and abuse. reCAPTCHA uses an advanced risk analysis engine and adaptive challenges to keep automated software from engaging in abusive activities on your site. It does this while letting your valid users pass through with ease.
...helps you detect abusive traffic on your website without any user friction. It returns a score based on the interactions with your website and provides you more flexibility to take appropriate actions.
WAF - Web Application Firewall:
A web application firewall (or WAF) filters, monitors, and blocks HTTP traffic to and from a web application. A WAF is differentiated from a regular firewall in that a WAF is able to filter the content of specific web applications while regular firewalls serve as a safety gate between servers. By inspecting HTTP traffic, it can prevent attacks stemming from web application security flaws, such as SQL injection, cross-site scripting (XSS), file inclusion, and security misconfigurations.
UBA - User Behavior Analytics:
User behavior analytics (UBA) as defined by Gartner is a cybersecurity process about detection of insider threats, targeted attacks, and financial fraud. UBA solutions look at patterns of human behavior, and then apply algorithms and statistical analysis to detect meaningful anomalies from those patterns—anomalies that indicate potential threats. Instead of tracking devices or security events, UBA tracks a system's users. Big data platforms like Apache Hadoop are increasing UBA functionality by allowing them to analyze petabytes worth of data to detect insider threats and advanced persistent threats.
All this solutions work based on a negative identification model, by other words they try their best to differentiate the bad from the good by identifying what is bad, not what is good, thus they are prone to false positives, despite of the advanced technology used by some of them, like machine learning and artificial intelligence.
So you may find yourself more often than not in having to relax how you block the access to the API server in order to not affect the good users. This also means that this solutions require constant monitoring to validate that the false positives are not blocking your legit users and that at same time they are properly keeping at bay the unauthorized ones.
Regarding APIs serving mobile apps a positive identification model can be used by using a Mobile App Attestation solution that guarantees to the API server that the requests can be trusted without the possibility of false positives, and I will explain it as a reply to your second question.
Second question
how can i be sure that none else can use the proxy except the Android app?
As I mentioned in the begin of my answer, the Mobile App Attestation concept may be your best option to tackle your problem.
The role of a Mobile App Attestation solution is to guarantee at run-time that your mobile app was not tampered with, is not running in a rooted device, not being instrumented by a framework like xPosed or Frida, not being MitM attacked, and this is achieved by running an SDK in the background. The service running in the cloud will challenge the app, and based on the responses it will attest the integrity of the mobile app and device is running on, thus the SDK will never be responsible for any decisions.
Frida
Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.
xPosed
Xposed is a framework for modules that can change the behavior of the system and apps without touching any APKs. That's great because it means that modules can work for different versions and even ROMs without any changes (as long as the original code was not changed too much). It's also easy to undo.
MiTM Proxy
An interactive TLS-capable intercepting HTTP proxy for penetration testers and software developers.
On successful attestation of the mobile app integrity a short time lived JWT token is issued and signed with a secret that only the API server and the Mobile App Attestation service in the cloud are aware. In the case of failure on the mobile app attestation the JWT token is signed with a secret that the API server does not know.
Now the App must sent with every API call the JWT token in the headers of the request. This will allow the API server to only serve requests when it can verify the signature and expiration time in the JWT token and refuse them when it fails the verification.
Once the secret used by the Mobile App Attestation service is not known by the mobile app, is not possible to reverse engineer it at run-time even when the App is tampered, running in a rooted device or communicating over a connection that is being the target of a Man in the Middle Attack.
The Mobile App Attestation service already exists as a SAAS solution at Approov(I work here) that provides SDKs for several platforms, including iOS, Android, React Native and others. The integration will also need a small check in the API server code to verify the JWT token issued by the cloud service. This check is necessary for the API server to be able to decide what requests to serve and what ones to deny.
CONCLUSION
In the end, the solution to use in order to protect your API server must be chosen in accordance with the value of what you are trying to protect and the legal requirements for that type of data, like the GDPR regulations in Europe.
DO YOU WANT TO GO THE EXTRA MILE?
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
I want to prevent someone from simply rooting the device and copying the app to redistribute. How do I make a downloaded device "account locked"?
My idea is to implement an encryption algorithm (one-way) that hashes the user's phone number and the execution of the code will perform a hash check every time (so it would fail if you use someone else's app on your phone).
However, since the app is downloaded the same way, if I implement the phone number hashing at first launch, the attacker could simply never launch the app and rip off the base version of the downloaded package.
So my question is that is there a way in the Google Play Store to provide the app with one of its variables changed? Or a clever way to ensure an installed application would not work anywhere else to prevent a direct copy package rip off? Maybe force a first launch so it configures itself immediately after download?
There's a short computer science answer, and a longer more helpful answer. The short answer is "If your app relies on a server to run, then it is easy. If your app runs entirely on the device it is theoretically impossible."
If your app relies on a server it's a simple process:
Use Google Play License Verification Library (LVL) to get a response cryptographically signed by Google to say this account bought this app. Do this in client side code on the app.
Send that response to your server, and check the signature. If it doesn't match, don't send the needed information to your app.
Because the user can't interfere with Google servers or your servers, and your app requires the server response to function, this is unbreakable.
However, if you check the response on the client side, or your app can work without the server response this can't be done (theoretically). An attacker can always remove the call to Google Play, the verification code, or fake your server response.
In this case you are in arms race with attackers. Most attackers are pretty lazy. If you use Google Play License Verification Library (LVL) to check your app was bought from Play, use ProGuard or another optimizer, and do a little bit of obfuscation to hide your code, some attackers can attack, but most won't bother, unless your app/game is super popular. Another useful technology is the SafetyNet attestation API which tells you if your app has been tampered with. But again, if you don't check the results server side it can be beaten, so client side is just an obfuscation arms race.
Beware, relying on something like phone number is a really bad idea:
what about Tablets which don't have a SIM card?
what about users with Dual SIMs?
what about users who change phone numbers or networks?
what about users who own more than one phone, who only need to buy your app once?
I want my web server to accept requests that originate only from my mobile app.
Since mobile apps are client apps that means that users can have the binary and decompile it or use a tool like Fiddler to interpret the API calls and reconstruct them (ex: in a console app).
So what I want is a way of generating a key that is bound to my app and the user's device.
The app is deployed in Windows Phone7, iPhone and Android. A cross platform solution would be ideal but something that works only in one platform is also more than acceptable.
Thanks!
Considering that you are deploying an application to a client, the actual answer here is 'not possible'. You can make it difficult for someone to fake an 'official id', but because you do not have control over the system that is making the requests, it could be your application or anything else pretending to be your application.
I'm writing a ringtone gallery app which ringtones reside on a server and they can be downloaded by user.
What I want is to check and verify if the connection is really from my app not other apps or a HTTP request generator. for example I don't like someone write an app that uses my back end and show his ads in the app. It's like image leaching in web site which is prevented by checking the referrer.
It's not possible to insert a key in the app as android apps can be decompiled so easily. I thought of gaining the app signature and send it's hash as a key, but it's like any app can access other apps signature hash.
what about writing part of app which do the communication in native code? is it decompilable as easy as java code?
I really can't think of any other way and I don't like others use my resources for their benefit.
There are a couple of things you can do.
Create your own Certificate Authority, ship a certificate with your app and use two-way TLS authentication. This does not protect against decompilation and reverse-engineering but protects traffic en route.
Use the advice in this slide deck to detect modifications and debuggers.
Use Jelly Bean's hardware-backed secure storage.
At the end of the day, though, DRM is a lost battle. If the user has root access, all bets are off, with or without obfuscation (which native libraries are). The only question is how important is your data. For 90% of applications, running it through ProGuard makes it nearly impossible to untangle (especially if you use data flow obfuscation). Along with the certificate approach, that should suffice for most things.
Alternatively, try to change your model, so that you're authenticating the user and not the app - that's far simpler!