The Amp Hour Electronics Podcast

A weekly show about the trends in the electronic industry.

You are here: Home / Guest Appearance / #265 – A Security Update with Michael Ossmann

#265 – A Security Update with Michael Ossmann

Play

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | RSS


6026542856_67c9fd0db5_z

 

Welcome back, Michael Ossmann!

After the outro…

  • Mike forgot to talk about the YARD Stick One, the product he is releasing next week! A prototype version was used in a DEFCON talk by Samy Kamkar about car hacking.

Thank you to joybot for the picture of the lock

Comments

    • Gah. Long. Excellent (and from Malcolm Gladwell) article compared to The Civil War (doc. film by Ken Burns, now 0xdeadbeef% more senseless in…whatever release format it’s ‘remastered’ in now.) Big on Pinto (gas tank legislation garbage) and Cobalt (airbags) eh…forensics. I already saw lament this year anyhow. But with New Yorker comics and links to more excellent stuff…

  2. I came home today from my RF and Digital Systems Labs to find Mike back on the show. This made my week! Thanks Dave, Chris, and Mike for all of your work; it has certainly been an inspiration for this aspiring electrical engineer. Happy Hacking!!

  3. Great show, great guest!

    Learning about SDR is still on my TODO list.. I’d be happy to just use SDR as an AM radio, but it would have been interesting to hear a follow-up question on what some of the unusual uses Michael heard about at those late night hacker meetings!

    Also, what does Michael think about the HackRF Blue campaign? I haven’t seen many people posting about it (ex. youtube dot com/watch?v=c7tGFUG4FFQ ). Did it go perhaps the way of the TangiBot?

  4. there is no way to transmit commands in car via sensors in can bus system, eseyst way to hack can bus is to put anything without your knowledge elm327+arduino+xbee or any sim900 device and some lines of code, i think there is no way to stop this as car manufacturers need to diagnose / firmware updates their cars. sorry for my english

    • Well, they did some neat groundwork in the tire sensor thing, according to some exegesis in Popular Science…might’ve just been plain Science, which is a pretty different org, but there it is…so it’s easy to think those systems (each a precious snowflake) are not the sensors that one can go expecting to smash the stack with. Maybe if someone decides a powered antenna is cool again…

  5. hi guys! very interesting show, but the fcc sdr thing leaves me with some questions. where is the difference between having one sdr for all frequencies and protocols, and many separate fixed boards for all f&p in fccs concern? does it make a difference if it was “jumper defined radio”? if it was “jdr” what would happen if a robot would set it? as a beginner maybe i missed the point somewhere, i would appreciate someone pointing it out to me. thanks.

    • when i follow the link in the shownotes it goes to hackaday, and they link to a document with 4 pages.
      thats most likely not what the nprm is about. i read into FCC 15-92 but i can only find the first
      89 pages. and page 124 “excluded devices” would be interesting. if this is what you were talking about.
      however rest assured that i wouldnt bother the fcc with my questions. especially when they want
      useful comments.
      to answer myself, separate products used separately seem to arouse less concern
      as they are each tested and an unsecured sdr is looked at to be able to do harm more
      easily. deliberate or not.

  6. I skimmed the FCC NPRM and saw that the new security requirement for grants only applies to U-NII devices (5Ghz). Food for thought if you’re thinking of making a formal comment.

    • This was in section §2.1033 (b) (10).

      Another relevant excerpt is in the Background section A.b. (point #18):

      “For a device to be certified as an SDR, in addition to demonstrating that the device complies with the applicable technical requirements, the applicant must also demonstrate that the device contains security features to prevent the loading of software that would allow the radio to operate in violation of the Commission’s rules.”

      This seems to imply that software modification is not prohibited outright as long as the function of the radio is protected.

      • as i understand point 18 you posted, software modification is prohibited. they dont care if you
        destroy your device.

        • In other news
          -regulators (and vendors) can’t (prevent the loading etc. etc.) because key lifetime is finite and RF ingenuity is not
          -they’re not providing test closure for faking it
          -they’re not talking about test closure for compliant operation and test-driven dev.
          -fugeddabout it

      • Yeah, there are some disclaimers on the datasheet for Cypress’ PRoC (Programmable Radio on Chip) which is the Bluetooth Low Energy bit with an ARM M0 and portends to do beacon and mobile pay things (but also has these neat peripherals…and the radio one isn’t glossed in the er…cover datasheet? per se.) http://www.cypress.com/products/proc-ble-bluetooth-smart

        So that one could run off jiggling around in the EM fields around you or a solar cell or what have you, but does *not* promise to run 4 cores of 64bit OS/eBPM/Docker over 4GiB DDR4.

        Separately on the show, I note that there are a lot of unglossed pauses creeping into the podcast in lieu of more heavily baked opinions on hand-soldered BGA46 and whatnot on project boards. Call the creative openings as they are or remove the bloc of chatter. These are moments that could have VADs trying to Close on the last of the socketed-magnetics PoE RJ-45 or clustering ARM9, if you can’t declare conformal coat the cure-all of art wave-solder power RF boards.

  7. sorry for the horrible formatting. is there a way to make it better
    other than counting characters?