- Site menu:
- Latest Discussions
- Latest Newswire
- Archives
- Submit Story
- Story HOWTO
- Syndicate
- E-mail Alerts
Secure Bittium Android Phone Has Split Personality
|
|
|
Comments (7)
Two words that do not belong in the same sentence are "secure" and "Android". I might could be more gullible about believing the security claims if this "phone" wasn't running Android.
There are several variations of 'secure' and 'phone'...
Android OS can be secured by disabling the ability to ever turn on Developer mode via USB debugging... and then adding a crypto trust certificate within the boot sequence. A voice call can be secured using encrypted voice apps.
The first component is how iOS works... and also Chrome OS.
Android's insecurity mostly arises from:
It's good to remember that 'rooting' a mobile device means that the device is now insecure.
Android OS can be secured by disabling the ability to ever turn on Developer mode via USB debugging... and then adding a crypto trust certificate within the boot sequence. A voice call can be secured using encrypted voice apps.
The first component is how iOS works... and also Chrome OS.
Android's insecurity mostly arises from:
- Side loaded apps
- Developer mode
- Insecure boot sequence
It's good to remember that 'rooting' a mobile device means that the device is now insecure.
>It's good to remember that 'rooting' a mobile device means that the device is now insecure.
Perhaps, but security as you may mean implies less usability for many, including me. There's always a trade-off to make between security and usability. The device that runs in a safe without any outbound connectivity is very secure but useless. A non-rootable Android device is a useless gadget for many, just as would be a Linux box without root.
Also, without any rooting, your phone service provider and Google can always mess with your data without your knowledge. So does security means : security for the big corps but not for the device owner ?
Security in IT has deviated to this point : you exist, you are a danger to me, either I kill you or I enslave you to my benefit. Is it the culture we are running after ?
Perhaps, but security as you may mean implies less usability for many, including me. There's always a trade-off to make between security and usability. The device that runs in a safe without any outbound connectivity is very secure but useless. A non-rootable Android device is a useless gadget for many, just as would be a Linux box without root.
Also, without any rooting, your phone service provider and Google can always mess with your data without your knowledge. So does security means : security for the big corps but not for the device owner ?
Security in IT has deviated to this point : you exist, you are a danger to me, either I kill you or I enslave you to my benefit. Is it the culture we are running after ?
>A non-rootable Android device is a useless gadget for many, just as would be a Linux box without root.
I certainly don't disagree. However, Android itself is not necessarily less secure because it's Android. And the choices available to and made by the end user are the source of the insecurity.
BTW: I don't personally use any commercially available mobile device. Many of the reasons are those you've posted... I don't trust Google, nor should I. I don't trust Apple, nor should I. However, I feel compelled to remind people that the very ability to 'root' a device shows that the device is insecure.
I've written this before somewhere... but I would be interested in a mobile device that allows the end user to load user generated keys as the trust root in the device. Such an architecture would allow the end-user complete control over enabling secure boot or disabling it, while also allowing the end-user control over the trust model of secure boot.
But... it will be a cold day on the sun facing side of Mercury before a commercially available consumer grade product includes this ability.
I certainly don't disagree. However, Android itself is not necessarily less secure because it's Android. And the choices available to and made by the end user are the source of the insecurity.
BTW: I don't personally use any commercially available mobile device. Many of the reasons are those you've posted... I don't trust Google, nor should I. I don't trust Apple, nor should I. However, I feel compelled to remind people that the very ability to 'root' a device shows that the device is insecure.
I've written this before somewhere... but I would be interested in a mobile device that allows the end user to load user generated keys as the trust root in the device. Such an architecture would allow the end-user complete control over enabling secure boot or disabling it, while also allowing the end-user control over the trust model of secure boot.
But... it will be a cold day on the sun facing side of Mercury before a commercially available consumer grade product includes this ability.
One thing that stands in the way of a rational discussion on "security" is the ambiguity that now exists with this word "security".
Security can mean many things:
1. From the perspective of a device manufacturer, security can mean that no user can access or change the firmware of the device.
2. From the perspective of a service provider, security can mean that no user can access services that are not contracted and paid for.
3. From the perspective of a device owner and user, security can mean that the user has control of his/her device and can allow or disallow accesses from external actors.
Relative to definitions 1 and 2, a device where the user has unrestricted root access will be considered insecure, in the view of the manufacturer and the service provider.
Relative to definition 3, a device where the user is prevented from having unrestricted root access to his/her device will be considered insecure by the user.
In order to achieve user-level security (definiton 3) the user will need unrestricted root access, packet capture, firewall and scripting. None of these criteria are fulfilled by either Android or iDevice.
The best a user can hope for now is that the blind trust in the manufacturer and service provider are warranted, and there is much evidence that such blind trust is misplaced.
Security can mean many things:
1. From the perspective of a device manufacturer, security can mean that no user can access or change the firmware of the device.
2. From the perspective of a service provider, security can mean that no user can access services that are not contracted and paid for.
3. From the perspective of a device owner and user, security can mean that the user has control of his/her device and can allow or disallow accesses from external actors.
Relative to definitions 1 and 2, a device where the user has unrestricted root access will be considered insecure, in the view of the manufacturer and the service provider.
Relative to definition 3, a device where the user is prevented from having unrestricted root access to his/her device will be considered insecure by the user.
In order to achieve user-level security (definiton 3) the user will need unrestricted root access, packet capture, firewall and scripting. None of these criteria are fulfilled by either Android or iDevice.
The best a user can hope for now is that the blind trust in the manufacturer and service provider are warranted, and there is much evidence that such blind trust is misplaced.
One of the major vulnerabilities is the cell modem. Security for the cell modem component of a phone is largely, "security through obscurity." I haven't heard anything about securing that, although voip apps using encryption could help keep the conversation secure. As a potential point of attack, however, I'm dubious as to whether any cell modem is secure, at least that is what I have heard...
>>I've written this before somewhere... but I would be interested in a mobile device that allows the end user to load user generated keys as the trust root in the device. Such an architecture would allow the end-user complete control over enabling secure boot or disabling it, while also allowing the end-user control over the trust model of secure boot.
>>But... it will be a cold day on the sun facing side of Mercury before a commercially available consumer grade product includes this ability.
Because the number one consumer support call would be "I can't get into my phone."
>>But... it will be a cold day on the sun facing side of Mercury before a commercially available consumer grade product includes this ability.
Because the number one consumer support call would be "I can't get into my phone."
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
Sign up and post (it is free) or Log in and post