[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] Android browser?
- To: "tor-talk@xxxxxxxxxxxxxxxxxxxx" <tor-talk@xxxxxxxxxxxxxxxxxxxx>
- Subject: Re: [tor-talk] Android browser?
- From: Mark McCarron <mark.mccarron@xxxxxxxxxx>
- Date: Mon, 9 Dec 2013 09:47:58 +0000
- Delivered-to: archiver@xxxxxxxx
- Delivery-date: Mon, 09 Dec 2013 04:56:16 -0500
- Importance: Normal
- In-reply-to: <85206C46A2B959A77D8D910D@F74D39FA044AA309EAEA14B9>
- List-archive: <http://lists.torproject.org/pipermail/tor-talk/>
- List-help: <mailto:email@example.com?subject=help>
- List-id: "all discussion about theory, design, and development of Onion Routing" <tor-talk.lists.torproject.org>
- List-post: <mailto:firstname.lastname@example.org>
- List-subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, <mailto:email@example.com?subject=subscribe>
- List-unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
- References: <1386459648.4122.2.camel@Neko-Warrior>, <3c033757-46ba-4997-b5d5-5fcd1afbdcab@xxxxxxxxxxxxxxxxx>, <7344615d-99bb-4478-94bd-b0f20dfdb659@xxxxxxxxxxxxxxxxx>, <52A5106D.3010704@xxxxxxxxxxx>, <7be38c11-e01b-4c1b-9852-39871bf7c519@xxxxxxxxxxxxxxxxx>, <85206C46A2B959A77D8D910D@F74D39FA044AA309EAEA14B9>
- Reply-to: tor-talk@xxxxxxxxxxxxxxxxxxxx
- Sender: "tor-talk" <tor-talk-bounces@xxxxxxxxxxxxxxxxxxxx>
> Date: Sun, 8 Dec 2013 23:57:56 -0300
> From: juan.g71@xxxxxxxxx
> To: tor-talk@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [tor-talk] Android browser?
> --On Monday, December 09, 2013 1:11 AM +0000 Mark McCarron
> <mark.mccarron@xxxxxxxxxx> wrote:
> > Mark McCarron
> > Nathan Freitas <nathan@xxxxxxxxxxx> wrote:
> >> On 12/07/2013 07:59 PM, Mark McCarron wrote:
> >>> I would be wary of Android. Its is complex to secure given the
> >> closed nature of most handsets.
> >> Do you have a mobile OS of choice that you feel is more trustworthy, or
> >> are you referring to smartphones in general?
> > It is the closed nature of the device that leaves a sense of distrust.
> > With respect to the OS, I don't think any OS could be declared safe
> > without some form of analysis by AI
In order to design secure code, especially when we are dealing with a large code base (like an OS), unit testing and manual review are unrealistic. A better approach is to develop a system of classifiers and train them against every possible category of error. We then submit our codebase to this classifier system and it generates a report indicating (with certain probabilities in complex scenarios) where the errors are. This is then published for everyone to see in the case of open source software. Each potential error is then reviewed, tested and submitted to the classifiers for reanalysis until given a clean bill of health.
To get an even better result from the classifiers, we would attempt to execute the code on particular chips or particular series of chips. This will reveal errors in computation/data transfer at the hardware level. This process is complex because we must use random sampling of given chips due to manufacturing variations. To become ultra secure and robust, we would expose the hardware to radiation, both electromagnetic and nuclear, to emulate jamming/remote manipulation and cosmic rays. The classifiers would reveal what form of errors occurred and how they were handled. Emulating remote manipulation by radio is the most complex aspect. Each wire inside a PC or device is effectively an antenna and typical shielding can be penetrated by a variety of means remotely. Thus it becomes possible to address the board and chips at the level of each wire or logic gate and inject code. This can cause a wide variety of issues and would normally be conducted by a sophisticated AI.
Then, we also have the reverse of this issue which I am sure everyone has heard of under the general banner of TEMPEST. This is general EM noise that can leak into the environment through everything from emitted EM to electrically coupled devices, power, data or telephone cables. There is also a more active version that uses the reflection of radar to determine the binary signal on any given wire. This noise is analysed by classifiers and the data and processing is reconstructed, hence the focus on processing encrypted data. It requires extensive engineering to minimise the leakage. I would need to run the numbers, but offhand I think that the emissions from a even a smartphone can be captured and reconstructed from LEO.
So, this is a very complex area. If you are serious about IT security, then you must attempt to design software and hardware that can match current espionage capability. Any weakness will be exploited, regardless of how unlikely you think that would be to occur.
> tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
> To unsubscribe or change other settings go to
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to