I have been playing around with the bluetooth options on android, and found an app that gave two connection options (secure and insecure).
I tried to find some information about it on the internet, but everything I found was pretty vague.
I have a general idea that Insecure isn't as safe as using Secure.
What are the advantages of using one over the other?
Should I always stick to Secure or should I go for insecure?
Thank you for your time,
What are the advantages of using one over the other? Should I always stick to Secure or should I go for insecure?
The only advantage in using insecure, is that you don't prompt the user when creating a communication channel (this one would be an easy prey "Man in the middle" attacks), but that doesn't mean that it will always work. Here's a question where the user complains about some devices asks for pairing while others don't.
Also this phrase comes from android API:
For Bluetooth 2.1 devices, the link key will be encrypted, as encryption is mandatory. For legacy devices (pre Bluetooth 2.1 devices) the link key will be not be encrypted. Use createRfcommSocketToServiceRecord(UUID) if an encrypted and authenticated communication channel is desired.
link
So, possibly in the future there would be no way to create an Insecure connection between two devices.
This answer your second question, you should stick with the Secure. When developing ('cause you can't know for sure if it's going to work) and for security reasons when using an app.
Related
I would like to be able to read traffic of my Android phone to see what data it's sending. It is running Android 9.
I have been able to use Charles but it can only read traffic that doesn't have SSL. It seems that if I was testing my own application there is something that I can set so it trusts the certificate, but I'm trying to get all traffic (all apps etc). I also have used the apps Packet Capture and NetCapture but they have the same limitation.
Is this video the guy is able to do it, but it appears to be an older version of Android where all apps would've trusted a user installed certificate.
Anyone got any ideas?
On Android 9 installing a custom root certificate usually does not affect the apps, therefore HTTPS connections performed by apps don't trust the certificate from Charles that you have installed. To change this you would have to manipulate every app or modify the Android system itself. Additionally some apps (e.g. Google services and PlayStore) perform certificate/key pinning which totally prevents breaking the HTTPS traffic unless the system is heavily modified:
You have to root your device and install XPosed + multiple modules to allow SSL/TLS interception like TrustMeAlready (or the older projects Just Trust Me and SSL Unpinning).
Another possibility is using Frida in combination with some anti-TLS checking/pinning script(s).
More possibilities are described in this Answer.
WARNING: Doing so totally eliminates the security of each and every SSL/TLS/HTTPS connections on your device Therefore not only you but everybody can intercept the connections made by a device modified this way!
To answer simply... No.
There are ways to look into the traffic but it won't show you much of anything worthwhile. You might be able to take a guess here and there but nothing will satisfy what you are after. I would not waste your time TBH.
Source: Had to do this for my job. Analyzed our app as well as many many others.
Check this out:
https://security.stackexchange.com/questions/83028/possibility-to-sniff-https-traffic-on-devices-without-installing-a-certificate/83039
First things first, I am writing this question after researching quite a bit.
Broader View of the issue
In this day and age, we require a more reliable way to perform peer-to-peer communication, preferably using technologies like NFC.
I mean we are in the year 2018 and I cannot believe that there isn't reliable means to communicate peer-peer between and ios and an android. I am talking about offline, close proximity/range communication, which can open up a new world of possibilities for mobile apps. Many of the apps we use to communicate with other devices require one or more of internet, login, credentials/authentication, etc. I am making this effort because most of the readers/users/developers do not actually know what has changed in 2018, so if anythings changed, I would love to hear it!
Hindrances
IOS has very weak NFC support, functionality-wise..?
IOS doesn't support Android Beam.
Not enough members are bothered to fix this or are helpless.
IOS doesn't support non-ios Bluetooth connection? (Doubt it/Tried but failed)
What I need
Efficient cross platform solution for communication between two different mobile devices preferably offline.
A way to send and receive money other than Apple Pay/GPay/Samsung Pay/iMessage/AndroidMessages, such as over NFC/Bluetooth preferably offline mutually, but connected to internet independently.
A way to automatically send data when two devices (different platforms and within ios) are in close proximity, without the need to login or register or any other steps. At least a way to trigger something upon nearing one device from the other, like NFC basically.
What I have
Working android application that uses android Beam to send and receive ndef messages, which is easy to do, between two android devices. So we can make the payment happen here in this case.
Questions arise when we try to proceed with android -> ios or vice versa.
I have read a lot of related questions where the answer is outright NO. However, am not taking time to write this question to be told it's not possible. I want the crowd here on stack overflow to help me find a way to workaround this situation. I know it is a lot to ask, but I feel this invention or discovery will help man app developers stuck in this same zone. This question should be answerable by someone who is ideally in the Fintech domain, and is an IOS developer or mobile developer, with working knowledge of card emulation, secure element, ios 11+ or ios 12 development, NFC, NFC tags, etc.
Questions/Ideas:
Can we use the secure element and NFC Tag with ios 12 or ios 11+ libraries to simulate this required functionality?
Does any third-party library get close to having the ios/iphone act like a NFC writer?
Can we simulate NFC writer for ios?
Can I simulate a tag on android device, have the iphone read it(do not want the apple pay popup somehow) and then follow through the next workflow via the internet? For example, if I had a sender and receiver (payments), since android supports a lot more than ios, can I simulate something on android so that either the apple pay thinks am a terminal of sorts and pays me electronically (securely of course), or at the least can I read apple pay credentials of sorts and simulate a terminal and accept a payment from ios on android?
Something on these lines, I know its not very clear, though I am trying to be clear and simple.
Suggested by others and why it is not a great solution:
WebRTC - Needs internet
alljoyn - Need only 2 device not 2+ and no need for server or client setup.
Relay Server not quite sure is offline or works
android-ios-peer-to-peer-architecture question talks a lot about it as well!
developing-mobile-p2p-payment-apps question, which seems to be relevant has NO answer.
why-android-ios11-cannot-communicate-via-nfc question talks about React Native. I for one have looked at PhoneGap and Nativescript which just have the same level of support for ios. In short, it won't work.
Any I left out, in short no solution.
Comments:
//Due to the fact that there is no solution, I feel even more motivated to post this question. I feel we should come together as one and fight for this right. I mean usually seemingly impossible questions are answered here, so I figured you guys could take this as a challenge. The challenge would be to find a legal loophole, an ethical approach, nothing unethical of sorts. So let me know if we can arrive at any positive conclusion! Thank you for being patient.
//I have read the rules and "do not ask" section, so I would just request moderators to check if there *can* be any answer before you flag it or take it down, by which I mean we just need one correct answer, and it can come from anyone or anywhere.
I am pleased to reveal that there has been demand for this and Google has released Nearby API as early as 2016. This is the way to move forward. This is a device independent API.
Please checkout Monzo Bank's Nearby Pay
Google and others claim it works with Ios as well.
It has been around since 2-3 years, which means there should be good support and documentation, though I might be wrong.
I hope this answer paves the way for others in my position! Good Luck!
Is it possible to get the network packets / stream prior to encryption? I mean if you are locally root and could compile pretty much everything yourself, even the kernel. Where would be the best place to do it, if it's even possible?
Somewhere inside the android framework might be a good point, where the encryption is actually done.
I know about all the mitm ways to attack, but it would be great if there would be a way without using a "proxy" or any other default gateway.
It would be used for debugging purposes on a special developer device.
I am asking the same question as here:
Secure contents in Documents directory
For android.
Are there equivalent concepts in android to what is presented here:
Protecting the app sandbox
My particular requirement is to protect files from rooted devices and also make them available only through application and for a certain lifetime.
Thanks
My particular requirement is to protect files from rooted devices
By definition, that is impossible.
First, anyone who has a rooted device has access to every file, anywhere in the device itself.
Second, encryption only helps the user protect their data from third parties. You, on the other hand, are trying to attack the user by preventing them from accessing their data. The only way you can try to do that via encryption is for you to be the only one with the decryption key, and since that decryption key has to be on the device for the device to be able to decrypt the file, any user who wishes to can rummage through your app, find the key, and decrypt the files themselves. The notion of encrypting files this way is called DRM, and there are two types of DRM: the ones that have been cracked and the ones that nobody has bothered trying to crack yet.
If you do not want the user to access this data, do not put it on their device.
Looking through Mighter's answers and given your concern over rooted phones it looks like its been discussed here.
http://source.android.com/tech/encryption/android_crypto_implementation.html
(a sub link i found somewhere in here http://source.android.com/tech/security/index.html)
Originally i was thinking you could use the ContentProvider and store your data in a database, i believe that can be protected, or you could at least encrypt the data within it. I wasn't sure that would answer your issue however. The android crypto implementation link i hope will cover your requirements. Though might be impractical due to version requirements.
Two notes:
Generally speaking your application could be only as secure as the operating system. In case the device is rooted, the operating system isn't secure anymore. So your application can't be secure either. For example there could be tweaks of operation system which will:
log keyboard input
subvert any calls (including calls to crypto API)
log any information which comes through HTTP(S).
Second note is that at some point you will need to provide your data (files) in clear (not encrypted) to 3rd party applications. As soon as you did this, they can copy it, send it to some server and you can't do anything about it. So, even if you provide access to these files for a limited time, they still can "leak".
That said, your simplest approach (as Emile pointed out) would be to use a ContentProvider, encrypt data within it and decrypt data when it's delivered to 3rd party apps.
An approach with higher complexity would be to use DRM (http://developer.android.com/reference/android/drm/package-summary.html) in case 3rd party apps support it.
Android utilizes Unix permissions to protect app sandbox. Each app runs under unique user and only that user has permissions to operate on /data/data/your.package.name folder. However, if target device is rooted, your app data can be compromised.
Some links:
http://source.android.com/tech/security/index.html
http://www.amazon.co.uk/dp/1430240628
http://developer.android.com/guide/topics/security/permissions.html
There is nothing safe about putting any kind of data onto an android device. They are ment to be open devices. If you are looking to protect your data again rooted users, then you would have to use a form of encryption. And depending on the sensitivity of the item, that may not even work (unless you use a real high end encryption which will then drain on performance). Dont trust Android with sensitive information is the only thing I can say.
I want to Programmatically create vpn profile; somehow i figure out how to access android.net.vpnmanager and android.net.vpn.vpnprofile (they are not part of offical API and are part of hide APIs) but they have no function create new vpn profile. any suggestions?
Using Hidden APIs is not a good idea as there is no guarantee that with an update they will still work as intended, moreover there is no guarantee that they will work in a consistent manner across different devices manufactured by different vendors.
Android 4.0 ICS has a VPN client API but again it allows you to create your own VPN client.
The only reason I can think of as to why you cannot access VPN settings just as you will access wifi settings is the inherent nature of VPN connections. Here is a link to the VPN features in ICS4.0. The first part of the document discuss these risks. You can still write your own client for your app.
http://developer.android.com/reference/android/net/VpnService.html
Another approach can be to use a third party VPN client and check if you can pass any actions to it via an intent. My recommendation if you are targeting ICS only will be to go with the client API as that you know how your code is working.
I thinkt that VPN Android isn't yet on a stable release, there are a couple of other clients besides the built-in there. But there's so many changes between the last versions of Android regarding the VPN and proxy settings. At the beginning there aren't any VPN support at all, then you can only get that rooting your device and now there's a kind of stable native VPN client inside Android but like you noted, lack of documentation in many aspects and other bugs too.
My recommendation would be to wait to create your code after we have a slightly more stable VPN Android and documentation. If you can't or don't want to wait, go forward with that undocumented API, it could change in the future but I don't see any better option right now.
If You are using a phone from Motorola look into using this as it has code to create working vpn connections using L2tp and Pptp
http://developer.motorola.com/docs/Motorola_Enterprise_Device_Management_SDK_Getting_Started/