Needs more hardware hacking dox

older
Re: [Cryptography] Craig Wright is...

Steve Kinney

27 Apr 2016 27 Apr '16

6:15 p.m.

Annual token on-topic post: Hardware considerations are inherent to the creation and solution of practical crypto problems, because good crypto is best solved by attacking the platforms it runs on. The 'internet of things' creates a massive comms attack surface, also best solved at the platform level i.e. signals discipline. When the scope of a project includes non-attribution by 3rd parties, hit and run network access via tightly controlled hardware is the only thing that can work against a well funded State adversary. I don't see much about hardware hacking on CPunks. I know that folks who have worked on digital circuit design and manufacture are lurking out there, also a bunch of ham radio people. Things they take for granted are utterly mysterious to lesser mortals, including "computer experts" focused on software and networking. Field tested cheat sheets on security oriented, low tech DIY hardware mods are among the most subversive things that can be published on the technical front. CPunks subscribers may or may not personally need those docs for the Nameless Mission or Big Show in our lifetimes, but others do need them now. How many lusers put tape over their laptop camera lens, but neglect to cut the pins on the microphone? How many people even know their shiny new car has a GPS receiver and an IP capable two-way radio enabling remote sabotage, and of these, how many know where the antenna connections are? There's a lot of room to educate a justifiably paranoid public on practical aspects of these and similar matters, if anyone has the time and interest to make that a Thing. :o)

Attachments:

signature.asc (application/pgp-signature — 490 bytes)

Show replies by date

Travis Biehn

27 Apr 27 Apr

7:03 p.m.

I'm working on influencing security in embedded, e.g., writing and designing secure systems (comprehensively, starting with arch & code.) It's an educational effort with embedded ISVs and OEMs at every step, you can presume the market, if they're thinking of security at all, is currently buying into 'fire-walling' and 'obfuscation' approaches. There are some interesting groups like We Are the Cavalry working on that as well. Some fun uses of Raspberry Pi computers as air-gapped PGP / KeyStores and Hardware Tor routers. DIY info-theoretic secure communications platforms (opto-isolators and so on.) On the topic of HWSec, I'm interested in detecting in-sil modification, allowing end-users to simply and easily verify their hardware in the same way that the OS community has become entranced with 'deterministic verifiable builds'. -Travis On Wed, Apr 27, 2016 at 2:15 PM, Steve Kinney wrote:

...

Annual token on-topic post:

Hardware considerations are inherent to the creation and solution of practical crypto problems, because good crypto is best solved by attacking the platforms it runs on. The 'internet of things' creates a massive comms attack surface, also best solved at the platform level i.e. signals discipline. When the scope of a project includes non-attribution by 3rd parties, hit and run network access via tightly controlled hardware is the only thing that can work against a well funded State adversary.

I don't see much about hardware hacking on CPunks. I know that folks who have worked on digital circuit design and manufacture are lurking out there, also a bunch of ham radio people. Things they take for granted are utterly mysterious to lesser mortals, including "computer experts" focused on software and networking.

Field tested cheat sheets on security oriented, low tech DIY hardware mods are among the most subversive things that can be published on the technical front. CPunks subscribers may or may not personally need those docs for the Nameless Mission or Big Show in our lifetimes, but others do need them now.

How many lusers put tape over their laptop camera lens, but neglect to cut the pins on the microphone? How many people even know their shiny new car has a GPS receiver and an IP capable two-way radio enabling remote sabotage, and of these, how many know where the antenna connections are? There's a lot of room to educate a justifiably paranoid public on practical aspects of these and similar matters, if anyone has the time and interest to make that a Thing.

:o)

-- Twitter https://twitter.com/tbiehn | LinkedIn http://www.linkedin.com/in/travisbiehn | GitHub http://github.com/tbiehn | TravisBiehn.com http://www.travisbiehn.com | Google Plus https://plus.google.com/+TravisBiehn

Steve Kinney

8:37 p.m.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/27/2016 03:03 PM, Travis Biehn wrote:

...

I'm working on influencing security in embedded, e.g., writing and designing secure systems (comprehensively, starting with arch & code.) It's an educational effort with embedded ISVs and OEMs at every step, you can presume the market, if they're thinking of security at all, is currently buying into 'fire-walling' and 'obfuscation' approaches.

There are some interesting groups like We Are the Cavalry working on that as well.

Some fun uses of Raspberry Pi computers as air-gapped PGP / KeyStores and Hardware Tor routers. DIY info-theoretic secure communications platforms (opto-isolators and so on.)

On the topic of HWSec, I'm interested in detecting in-sil modification, allowing end-users to simply and easily verify their hardware in the same way that the OS community has become entranced with 'deterministic verifiable builds'.

-Travis

I was thinking about step by step walk-throughs on things like: * Generic and model-specific methods of reversibly (and not) disabling automotive ECM radio. * Positively preventing laptop WiFi signals from being broadcast before the MAC address has been scrambled. * Disabling built in microphones in computers and other network capable devices etc. Most of the necessary info is on the networks, IF one knows the applicable language and which sources to focus searches on. Right now I don't have the time for a new project but it's on my long term to-do list until or unless somebody else does it. Field testing - actually doing the things described - makes a huge usability difference, especially when writing for end users who do not have a background in tinkering with electronics. Things technologists take for granted and would not mention can pop up as unbeatable obstacles when first timers are trying to follow "simple" instructions. A great example: http://www.turnpoint.net/wireless/cantennahowto.html :o) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJXISMcAAoJEECU6c5Xzmuqj0sIAK5BrO1RfW3hJYyYu2V7eqfM FcuMwRYjWenprNZwyB7CneNX9jSDT7xU0ApmkPzfzBckJfCKqliqQ/4qj6dgoyRr 2Kc6/AjH7R9oHrsdnaot3wrGvdBfv14TgSPqHBnZnY60qqvl938T0j/lySD1lS05 EeGixB2MgKQxQbHU4sjDyJyYfyibR37QG8rTYvmnveMRlbZdN9SY02i7+AfzizIp 3Wo7JYk8nQgAt8fwE3MZnVLsWvz23wq77SaqoTXbKEA/We4oqAN1RiqH2bYCZVHd UqJjbeuGPEBLUsGJkuPTMylY/KSquhL+LpOecLH/5l2+KNVJgLOHGS4KjwPaCZk= =zI8b -----END PGP SIGNATURE-----

Travis Biehn

9:07 p.m.

Ahh, neat project list - neutering your devices surface is certainly an interesting bent. I dig efforts to liberate access to embedded devices running flavors of linux - usually you can find a guide to root shells on just about anything that runs the kernel. RTOS, you aren't so lucky. Your bits are much more complicated in physical land - things are just so much easier when a 1 is a 1 and a 0 is a 0, no? -Travis On Wed, Apr 27, 2016 at 4:37 PM, Steve Kinney wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 04/27/2016 03:03 PM, Travis Biehn wrote:

...
I'm working on influencing security in embedded, e.g., writing and designing secure systems (comprehensively, starting with arch & code.) It's an educational effort with embedded ISVs and OEMs at every step, you can presume the market, if they're thinking of security at all, is currently buying into 'fire-walling' and 'obfuscation' approaches.

There are some interesting groups like We Are the Cavalry working on that as well.

Some fun uses of Raspberry Pi computers as air-gapped PGP / KeyStores and Hardware Tor routers. DIY info-theoretic secure communications platforms (opto-isolators and so on.)

On the topic of HWSec, I'm interested in detecting in-sil modification, allowing end-users to simply and easily verify their hardware in the same way that the OS community has become entranced with 'deterministic verifiable builds'.

-Travis

I was thinking about step by step walk-throughs on things like:

* Generic and model-specific methods of reversibly (and not) disabling automotive ECM radio.

* Positively preventing laptop WiFi signals from being broadcast before the MAC address has been scrambled.

* Disabling built in microphones in computers and other network capable devices

etc.

Most of the necessary info is on the networks, IF one knows the applicable language and which sources to focus searches on. Right now I don't have the time for a new project but it's on my long term to-do list until or unless somebody else does it. Field testing - actually doing the things described - makes a huge usability difference, especially when writing for end users who do not have a background in tinkering with electronics. Things technologists take for granted and would not mention can pop up as unbeatable obstacles when first timers are trying to follow "simple" instructions.

A great example: http://www.turnpoint.net/wireless/cantennahowto.html

:o)

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1

iQEcBAEBAgAGBQJXISMcAAoJEECU6c5Xzmuqj0sIAK5BrO1RfW3hJYyYu2V7eqfM FcuMwRYjWenprNZwyB7CneNX9jSDT7xU0ApmkPzfzBckJfCKqliqQ/4qj6dgoyRr 2Kc6/AjH7R9oHrsdnaot3wrGvdBfv14TgSPqHBnZnY60qqvl938T0j/lySD1lS05 EeGixB2MgKQxQbHU4sjDyJyYfyibR37QG8rTYvmnveMRlbZdN9SY02i7+AfzizIp 3Wo7JYk8nQgAt8fwE3MZnVLsWvz23wq77SaqoTXbKEA/We4oqAN1RiqH2bYCZVHd UqJjbeuGPEBLUsGJkuPTMylY/KSquhL+LpOecLH/5l2+KNVJgLOHGS4KjwPaCZk= =zI8b -----END PGP SIGNATURE-----

Blibbet

10:47 p.m.

...

...
I don't see much about hardware hacking on CPunks. [...]

I maintain FirmwareSecurity.com, a blog focused on firmware security and developmen, mostly UEFI-focused. Hardware security is a topic, since most firmware is very hardware-specific. It isn't a fancy blog, I still haven't learned WordPress, it is mostly a paragraph or two of text and a few URLs for a topic. I try to put personal research here so others can benefit. The sad thing is I was looking for a better source and haven't found it, so my lame blog is nearly the best there is. :-( There are a few who teach hardware hacking classes, look at the pre-conference training offerings of the normal infosec conference circuit events, Black Hat, Def Con, Can Sec West, Infiltrate, REcon, Troopers, etc. Look into the Stanford.edu LiberationTech mailing list, there's a lot of personal technology security/privacy issues there, more for activists but similar to OP's list of topics. I'm not sure of the latest citizen-focused guidance for physical+cyber security. I expect there's a link to the contenders on the LiberationTech list. There is more happening on hardware/firmware security on Twitter than on mailing lists. It would be nice to have a hardware/firmware hacking mailing list. Not sure if some of the younger security researchers and hackers will be able to spend time away from Twitter/Facebook/Reddit to contribute to a mailing list, though. :-(

...

I'm working on influencing security in embedded, e.g., writing and designing secure systems (comprehensively, starting with arch & code.) It's an educational effort with embedded ISVs and OEMs at every step, you can presume the market, if they're thinking of security at all, is currently buying into 'fire-walling' and 'obfuscation' approaches. [..]

I'd love an URL to the above embedded security work, if any exists!

dan＠geer.org

28 Apr 28 Apr

3:30 a.m.

| Field tested cheat sheets on security oriented, low tech DIY hardware | mods are among the most subversive things that can be published on the | technical front. CPunks subscribers may or may not personally need those | docs for the Nameless Mission or Big Show in our lifetimes, but others | do need them now. Yes. I want to know how to kill the black box on a new car so I can stop having to weld up the rust on my existing 24 year old ride. --dan

Travis Biehn

1:41 p.m.

I think there is not any single black box module component. All of the things are 'storing data' 'all the time' 'intentionally logging' 'inadvertently logging' - then data are recovered from all available (non-smoldering) modules. -Travis On Wed, Apr 27, 2016 at 11:30 PM, wrote:

...

| Field tested cheat sheets on security oriented, low tech DIY hardware | mods are among the most subversive things that can be published on the | technical front. CPunks subscribers may or may not personally need those | docs for the Nameless Mission or Big Show in our lifetimes, but others | do need them now.

Yes.

I want to know how to kill the black box on a new car so I can stop having to weld up the rust on my existing 24 year old ride.

--dan

Steve Kinney

4:16 p.m.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/28/2016 09:41 AM, Travis Biehn wrote:

...

I think there is not any single black box module component.

All of the things are 'storing data' 'all the time' 'intentionally logging' 'inadvertently logging' - then data are recovered from all available (non-smoldering) modules.

The "black box" in recently made motor vehicles is the Electronic Control Module, a computer usually located under the dashboard on the passenger side, right against the firewall. It reads sensors and runs servos throughout the engine, and stores diagnostic error messages about same. Today's version of a "racing cam" is a custom chip installed in the ECM. A modern automotive engine can not run with its ECM disconnected. The ECM also accepts inputs from the driver's controls, runs the anti-lock braking servos, and controls dashboard readouts. Some can even drive the car, as Michael Hastings seems to have learned the hard way. In recent vehicles equipped with GPS, the receiver should normally be integral to the ECM, as is the radio that makes push updates to ECM software and/or hostile remote control of the vehicle possible. Factory supported LoJack style security systems and RF door keys would also be integral to the ECM. Details will vary, but ECMs made by one manufacturer for all of its vehicles are usually very similar to one another. Maintenance manuals relevant to the make, model and year of the vehicle in question will "tell all" - or at least, tell enough - if you can access the right ones . Most paranoid motor vehicle end users (I almost said "owners," silly me) would be quite happy with their ECM's functions, IF its radios were silenced. Once the physical components of those radios have been identified, "let me count the ways" to disable them without killing the vehicle. And that's were a project digging out those details, doing constructive sabotage and publishing the details and results in one place for e-z user access seems like a good idea to me. :o)

...

On Wed, Apr 27, 2016 at 11:30 PM, mailto:dan@geer.org> wrote:

| Field tested cheat sheets on security oriented, low tech DIY hardware | mods are among the most subversive things that can be published on the | technical front. CPunks subscribers may or may not personally need those | docs for the Nameless Mission or Big Show in our lifetimes, but others | do need them now.

Yes.

I want to know how to kill the black box on a new car so I can stop having to weld up the rust on my existing 24 year old ride.

--dan

-- Twitter https://twitter.com/tbiehn | LinkedIn http://www.linkedin.com/in/travisbiehn | GitHub http://github.com/tbiehn | TravisBiehn.com http://www.travisbiehn.com | Google Plus https://plus.google.com/+TravisBiehn -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJXIjdhAAoJEECU6c5XzmuqVgoH/1A9FUsr4tsvVuAESJAx+rcQ 6SByMIY+SuhFYyZb9erpAdtFnNJwVR0sBJSJM9ARtXZIE3ppVaxAQkcsOoESOjju +pDkZkC4W43bTlivacM6pZO6quu2v2hH4J/k4CsNfSbaK8RESwRvdYfgBtlBM3LX l6p9m9WzWTK/UfCqogM60iFFWoXI8njU/t9YodyVZ841MuPjENNck4gLZ+grvf6v HGTi3aY5Lv+mobz/abH6QfecJao6oPRmVaqyNVaSX3vqeympO8ByFeHP0y3OPsff cnNXR58lbFJyZrs/gy9e+DScb4Pha6pktbsEz+tAQdgA4FNE/U57gZ9gmP4byuA= =y92C -----END PGP SIGNATURE-----

Georgi Guninski

29 Apr 29 Apr

2:47 p.m.

...

How many lusers put tape over their laptop camera lens, but neglect to cut the pins on the microphone? How many people even know their shiny

Wouldn't this kill the main functionality of the hardware (smart) phone? OT: is enough tinfoil around hardware good enough Faraday cage? ;)

Steve Kinney

3 May 3 May

2:08 a.m.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/29/2016 10:47 AM, Georgi Guninski wrote:

...

...
How many lusers put tape over their laptop camera lens, but neglect to cut the pins on the microphone? How many people even know their shiny

Wouldn't this kill the main functionality of the hardware (smart) phone?

OT: is enough tinfoil around hardware good enough Faraday cage? ;)

I would have thought it obvious that I was talking about laptops, where people (even Fox Muldur per a recent X Files episode) actually do that tape thing. Everyone knows that a phone has a built in microphone, nobody forgets that. Portable workstation computers? Not so much, except those who do use them routinely for teleconferencing. Hence the comic aspect of tape over the lens with a live microphone ignored. If one is concerned about being tracked during a specific time frame via a "smart" phone, the solutions include: Leave it home, ask a friend to take it on a trip with them, or pull the battery. Which to use depends on the cause of that concern and other unique parameters. Since user surveillance, tracking and profiling is commercially valuable to the vendors of IOT gadgetry, software solutions will be placebos, or at best an arms race with the vast majority of end users on the loser's bench for the duration. Fact of the matter is, the most practical and reliable means of addressing privacy concerns related to the "internet of things" is at the gross hardware level DIY level, by disabling sensor and/or comms components where and as the user deems this a good trade off. :o) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJXKAgkAAoJEECU6c5Xzmuqd7UIAMw4p7A+n9h+SIxhCaxJ9afu KAo817i5lun2RivghLHTMXyRWRM+gcETDdBMHLMK1XomlMWzuUO8btFV3A3SIHct amF6bCHtQwOs3etAcQwzIMaz5JLIrSK69nPwXwMtouvsXD5XC1D2qSa47iWXj1ws 2aCufG4FGdVe/gxJ81MD1X5xZ/CylN4fTjIIgrAXvkCkHQc/WccuuUm4zrumqwAJ wtG1mwL5PWNUp7tpmA67km4vVvM0WT84eyKOEkzV/QNP9AOKHmHOmGEL3KVfPKv9 Fp+8aQ8nkSM36Jmp/L/FdMqZ9STTsY7yWHC9T8FutCNYRMhzPk+jfL3hc52iW+U= =ORh/ -----END PGP SIGNATURE-----

3061

Age (days ago)

3067

Last active (days ago)

List overview

Download

9 comments

5 participants

participants (5)

Blibbet
dan＠geer.org
Georgi Guninski
Steve Kinney
Travis Biehn