IoT VILLAGE - I'm the One Who Doesn't Knock: Unlocking Doors from the Network

Video thumbnail (Frame 0) Video thumbnail (Frame 2012) Video thumbnail (Frame 8245) Video thumbnail (Frame 9707) Video thumbnail (Frame 11281) Video thumbnail (Frame 12084) Video thumbnail (Frame 12819) Video thumbnail (Frame 13763) Video thumbnail (Frame 15062) Video thumbnail (Frame 16807) Video thumbnail (Frame 18164) Video thumbnail (Frame 19373) Video thumbnail (Frame 27493) Video thumbnail (Frame 30485) Video thumbnail (Frame 31903) Video thumbnail (Frame 43151) Video thumbnail (Frame 44166) Video thumbnail (Frame 50401)
Video in TIB AV-Portal: IoT VILLAGE - I'm the One Who Doesn't Knock: Unlocking Doors from the Network

Formal Metadata

IoT VILLAGE - I'm the One Who Doesn't Knock: Unlocking Doors from the Network
Title of Series
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Release Date

Content Metadata

Subject Area
In 2017, I discovered that a popular IP-based door access control system (badge reader and door lock controller) used poorly-implemented cryptography. Through binary analysis and live testing against a functional device, I was able to construct an exploit that would unlock the door without talking to the central authority database or logging the door open event. I'll walk the audience through the steps that made me realize there was a problem, through the binary analysis, and then finally into building a working exploit.
Computer font Multiplication sign Projective plane Control flow Video game Bit Information security Information security Software bug
Point (geometry) Server (computing) Implementation Building State of matter Multiplication sign Set (mathematics) Client (computing) Distance Magnetic stripe card Field (computer science) Number Zugriffskontrolle Fraction (mathematics) Frequency Sign (mathematics) Different (Kate Ryan album) Term (mathematics) Operator (mathematics) Energy level Office suite Determinant Local ring Information security Control system Physical system Installation art Information Server (computing) Plastikkarte Voltmeter Physicalism Bit Staff (military) √úberlastkontrolle 10 (number) Connected space Type theory Personal digital assistant Order (biology) Data center Point cloud Configuration space Remote procedure call Communications protocol
Point (geometry) Area Focus (optics) Patch (Unix) Multiplication sign Patch (Unix) Mathematical analysis Physicalism Control flow Mathematical analysis Area Software Office suite
Decision theory Decimal Direction (geometry) Multiplication sign Binary code Mathematical analysis Streaming media Mathematical analysis Product (business) Message passing Sweep line algorithm Quicksort Advanced Encryption Standard Communications protocol Local ring Control system Row (database)
Advanced Encryption Standard Cryptography Software Encryption 1 (number) Computer network Encryption Cryptography Communications protocol Product (business)
Web page Mobile app Scripting language 1 (number) Binary code Mathematical analysis Black box Arm Number Revision control Object (grammar) String (computer science) Core dump Determinant Local ring Firmware Computer architecture Scripting language Modal logic Binary code Bit Binary file Cartesian coordinate system Symbol table Personal digital assistant String (computer science) Website Right angle Object (grammar) Library (computing) Firmware
Point (geometry) Default (computer science) Computer program Server (computing) Key (cryptography) Computer file Interface (computing) Multiplication sign 1 (number) Computer Symbol table Mechanism design Mechanism design Exterior algebra Programmer (hardware) Computer configuration Computer configuration Configuration space Right angle Object (grammar) Game theory Physical system Default (computer science)
Ciphertext Building State of matter Multiplication sign 1 (number) Set (mathematics) Binary code Insertion loss Mechanism design Mathematics Sign (mathematics) Different (Kate Ryan album) Core dump Encryption Local ring Error message Sanitary sewer Control system Binary code Drop (liquid) Bit Storage area network Sequence Connected space Type theory Message passing Data management Telecommunication Order (biology) Website Right angle Encryption Quicksort Figurate number Data structure Reverse engineering Point (geometry) Dataflow Divisor Patch (Unix) Exploit (computer security) Mathematical analysis Drop (liquid) Power (physics) Number 2 (number) Product (business) Sequence Frequency Peripheral Bridging (networking) String (computer science) Message passing Traffic reporting Metropolitan area network Authentication Installation art Game controller Noise (electronics) Dependent and independent variables Key (cryptography) Mathematical analysis Correlation and dependence Group action Cartesian coordinate system Cryptography Equivalence relation Number Software Personal digital assistant Partial derivative Communications protocol Window Local ring
Axiom of choice Presentation of a group Installation art INTEGRAL Multiplication sign Workstation <Musikinstrument> 1 (number) Mereology IP address Public key certificate Proper map Information technology consulting Neuroinformatik Software bug Medical imaging Cryptography Computer configuration Formal verification Endliche Modelltheorie Office suite Information security Vulnerability (computing) Physical system Data integrity Electric generator Public key certificate Transport Layer Security Physicalism Bit Funktionalanalysis Entire function 10 (number) Message passing Telecommunication Order (biology) Interface (computing) System programming Configuration space Right angle Quicksort Information security Resultant Thomas Bayes Laptop Point (geometry) Implementation Server (computing) Open source Constraint (mathematics) Transport Layer Security Flash memory Virtual machine Product (business) Revision control Latent heat Internetworking Term (mathematics) Software Computer hardware Software testing Message passing Firmware Booting Fingerprint Authentication Installation art User interface Addition Distribution (mathematics) Multiplication Scaling (geometry) Key (cryptography) Information Interface (computing) Plastikkarte Independence (probability theory) Computer network Database Cryptography Sign (mathematics) Software Personal digital assistant Key (cryptography) Pressure Routing
Point (geometry) Axiom of choice Slide rule Server (computing) Context awareness Link (knot theory) Multiplication sign Microcontroller Mereology Public key certificate Coprocessor Twitter Number Neuroinformatik Blog Hacker (term) Term (mathematics) Public-key infrastructure Computer hardware Vulnerability (computing) Slide rule Public key certificate Key (cryptography) Transport Layer Security Sound effect Volume (thermodynamics) Bit Cryptography Twitter Connected space Elliptic curve Sign (mathematics) Software Personal digital assistant Blog Calculation Infinite conjugacy class property Right angle Musical ensemble Communications protocol
Server (computing) Multiplication sign Range (statistics) 1 (number) Microcontroller Power (physics) Number Element (mathematics) Minimal surface Blog Term (mathematics) Bridging (networking) Different (Kate Ryan album) Computer hardware Encryption Cloning Office suite Data conversion Information security Booting Identity management Slide rule Key (cryptography) Plastikkarte Cryptography Public-key cryptography Twitter Electronic signature Routing Reading (process)
okay so my name is David Tomczyk I work on the Google security team I'm a senior
security engineer on the Google security assessments team I predominantly conduct red teaming about 80% of my time at Google we also have the opportunity to do 20% projects and I spend my 20% time breaking IOT those occasionally intersect and I'll tell you about one time when they did but I will also tell you first some personal interests I like to break IOT stuff for fun I've been known to buy many many IOT devices solely to see how they play and sometimes find bugs in them I also like to make electronic things like you know badge life so I'm gonna start by telling you a little bit of a story about how I broke some door access controllers and what actually led me to the realization something was broken I wasn't actually looking at the door access controllers on purpose I kind of stumbled across the realization something was broken and then had to spend the time making an exploit and then I want to talk about how we fix it right I know that stories about how we break things are really really interesting but we actually only make impact as security engineers if we get a fix made from it so first I'm
gonna tell you like how did or access controllers work right like many of you probably work in office buildings that use some kind of card based system for access and so you probably interact with these all day long but you probably don't think very much about how it works you conceptually at a high level probably know oh I have an access card there's a reader the reader talks to a server and the server decides whether or not you're let in but it turns out that the actual implementation of this is a little bit more complicated you have the badge reader you have a local controller that's present at the badge you have the connection to the lock on the door and then you have a local controller which will usually be in an IDF or a similar facility within the building and then the badge server may be sitting in fact in a data center somewhere or sitting you know even in a cloud facility or a Cola so there's different protocols in use at different points along this connection the most common protocol that is used on the wire from the physical badge reader itself to the door controller is a protocol called Wiegand which came from actually magnetically encoding on the card and actually represents the flips in a magnetic field now many of our cards now are in fact using a proximity system and have no Mack stripe on them at all but in order to maintain backwards compatibility they kept using the same wire protocol between the badge reader and the door controllers and even though we have door controllers now with IP that didn't exist at the time the Wiegand protocol became popular because these installations may last for tens of years then you can end up with a case where you're backwards compatibility on each side is maintained for a long period of time beyond that you have IP in this particular installation from the door controller to the local controller and then you have IP traffic again between the local controller and the badge server as to actually unlocking the door usually that's just a straight 12 volt signal to a physical lock or to one of those magnetic locks that will release the door so that you can open it so let's go through a typical scenario in terms of swiping your badge and getting access to a facility so the first thing that will happen is you'll swipe your badge against the badge reader and the badge reader will immediately relay the information about that badge to the door controller and you'll say hey badge number 335 has just swiped the door controller we'll say okay I need an access check for door number one because the badge reader doesn't know which door it's actually installed for but the door controller does so it says I need an access check for door number one badge number is three three five I'm passing it on to the local controller the local controller basically passes it on to the badge server in order to find out this information the badge server is what will actually make the authoritative determination says looks good this door this guard is allowed access to this door okay the local controller says badge okay and it tells the door controller open the door numbered number one and at that point you get your green light on the badge reader and you get your unlock signal to the door lock now this in practice only takes a fraction of a second you know typically a few tens of milliseconds or a few hundreds of milliseconds to happen although I'm sure some of you have swiped and then had that really long pause before it unlocked and well that's probably a sign of network congestion or failure along the way so this is the typical scenario for a door access controller setup but there's also some other use cases of all of this infrastructure so let's say that you're at a remote facility and you forgotten your badge and you want to be led into that facility you maybe call your company's security operations center and convince them that you're the right person and that you should be allowed access but how are they going to do that are they going to send a security guard to come drive out to the remote facility and let you into the system or into the facility no it actually turns out that there's a way
that they can from a remote client PC connect to the badge server and just say it send an arbitrary command to unlock door number one and that command goes to the badge server to the local controller to the door controller where it's converted to an analog signal and the door gets unlocked so this is a remote access and remote unlock capability is very common in these systems and almost universally implemented for these particular types of cases it also helps if the badge reader fails they can send a remote command to put the door in an unlocked state for a certain period of time or they can do things like changing the configuration for the door on the fly or other settings so this is a possibility as well and you'll notice that in this case it's not associated with a badge type it's just associated with a command that comes from the control PC in the Security Operations Center or wherever the security staff may be so now onto our story once upon a
time I'm executing a red team and the threat the focus of our red team's does not in fact these two are controllers just happened to be on a network that happened to have a patch panel in an area accessible to contractors so we're like cool let's plug into this patch panel and see what's on this network we didn't even know which network segment we were on at that point but we realized shortly afterwards after we started seeing traffic we were unfamiliar with and started tracing the cables and they went to the locks and the door controllers next to each of the doors and we're like oh cool maybe this is some physical access stuff so we dumped some of the traffic and but we didn't immediately see a way that we could do a replay attack or otherwise influence the door controllers and since we were doing one where we were physically on-site at one of our facilities and not in fact in our office we didn't have a whole lot of time for analysis at this point but I was like you know what I like to break IOT devices I'm coming back for you later and so I started looking at the traffic
and trying to figure out why there was something that was just bothering me about the traffic and so I started looking at this and I was like there's something suspicious here and I can't really put my finger on it so I started looking at the traffic in just one
direction at a time and so this is three messages in a row three packets coming from the door controller to the local controller and there's something really really strange about these packets and if you haven't figured out what that is
turns out the first 36 bytes of each message are the same which that's pretty weird the data looks very random it doesn't look like it's some sort of plain text but at the same time 36 bytes are the same and then the remaining bytes are completely different so at first I was thinking maybe it's some kind of proprietary binary protocol or something like that but replaying these raw packets wasn't getting me anywhere so I decided I needed to do some more analysis so I went and looked at the literature for this particular product and they make the claim a aes-256
network encryption if I recall correctly there was also something about this being used to protect top-secret government data in the brochure well so I'm pretty sure looking at that pcap that they're doing it wrong because
usually when you see encrypted data you shouldn't have a to it like that I'm not a cryptographer but I have seen a lot of encrypted protocols and the ones that are well designed don't have 36 repeating bytes in them so I started thinking okay maybe they're doing something weird with this and they're encrypting each message or
something like that but I couldn't really figure it out from a black box approach having only the peek app so I started looking at the endpoint devices and they're basically armed devices running gnu/linux some sort of debian derivative it turns out it may be actually pure Debian from several years ago and the actual firmware applications that are used do you do the door access control are supplied as Det packages and in fact you could download the updates from the vendor site and get the whole dab that contains all of the application and all of the libraries that they're using running on each of their applications but these packages were actually several hundred megabytes so I had a number of binaries libraries scripts and I wasn't sure where to begin so what tools do we to turn to to begin
well there's a bunch of shared objects and it turns out shared objects have to have some of the symbols left in right you can't completely strip a shared object or else you can't do runtime linking against it so it turns out the fastest way to actually find out the names of the symbols and a shared object and I know there's some way to do with object dump or nm or those other tools but it turns out just running strings against them is an amazingly effective way to get the names of symbols out of there and then I don't have to look at them and pages for mm or object um and you could also use Ltd to figure out which binaries we're linking against those shared objects now there's a bit of a wrinkle there if you've never worked on an on x86 architecture and that is that you need ldd that's been compiled particularly for the architecture that you're dealing with so in this particular case you need the army ABI version so that ldd can run against these particular ones so I know that there's better and much nicer ways of doing this but it turns out that if something is stupid and it works then it's really not stupid so
after a while I come across this in a shared object symbol still named and it's labeled default AES key it's also named default AES IV I've fudged a few of the bytes I'm sorry legal insisted we have here though defaults but you know what I was like okay these are the defaults maybe these aren't the ones that are actually being used and I spent a lot of time looking through the binary I was like alright so where do you change the key like is it loaded from a configuration file is it loaded from the interface is it loaded from an upstream server like how do you change the key it says default so there must be a way to change the key and I could never find a way to change the game and I was really really confused so I was like ok what
does default really mean default means a pre-selected option adopted by a computer program or other mechanism when no alternative is specified by the user programmer it is technically correct the programmer did not let you specify an alternative so it is the default when we went to the vendor with our findings I said hey it's labeled as the default key please tell me was I just an idiot and couldn't find a way to change it and they were like no we never thought a customer would need to change it and we were afraid that if they changed it in one place it would break their system and would result in all these support costs because the keys wouldn't be the same on their all their devices thanks guys all right so I have a key so what can I do with this right like I mean finding a key is cool but at that point I can get some plaintext well
first I wanted to make sure that it was the right key so I started decrypting and for anyone who's ever looked a little bit at crypto it turns out that plaintext has lower entropy than Krypton the ciphertext and so a really good sign was that I had long strings of null bytes in it once I did the decryption that hey this is probably some binary pact protocol there's lots of zero values and so I've been able to successfully decrypt it but it also turns out they weren't using any sort of a Mac or any authentication on the encryption so I couldn't be a hundred percent sure but it would have been a pretty strange coincidence to get a bunch of no bytes and lower entropy if I had the wrong key unfortunately the plaintext still looked like a bunch of noise just lower entropy noise than the ciphertext in general plaintext is you is useless to you unless you can assert some sort of meaning to it and figure out what its structure and at this point I had the rough equivalent of decrypting sans decrypting it and finding out that I had Sanskrit inside I didn't know what it meant but it was no longer a secret and it turns out it was some custom binary protocol and so I had to start digging further into their binaries by doing binary analysis to try to get an understanding of how this works so I started looking at bad reads with correct badge numbers and their responses that were coming back from the local controller and getting the door unlock messages back from the local controller and also coordinating correlating with the door status messages in order to figure out oh this message says that the door is unlocked this message says that the door is locked it turns out that their protocol actually though has some like 40 different message types in it and so I couldn't figure out all of the messages many of them weren't probably relevant they were messages to change various settings and timeouts and things like that right there's a certain amount of time the door remains unlocked after you swipe your badge for example and that can be five seconds it can be a minute depending upon the circumstances many of them are still unknown I couldn't really justify fully reverse engineering their protocol at that point but so I wanted to get a working exploit out of this right like we didn't actually need it for a red team at this point but like there's just something about the satisfaction of breaking a physical device and actually seeing that physical impact the real world so in this particular case hearing the click of the lock mechanism opened the door I was like all right I have to keep going at this I can probably justify another two or three days before my manager says well we found enough to you know report it and move on I was like okay I'm gonna try to figure this out so I start looking at it and there's some sequence numbers in the flow and this is actually why the replay attack didn't work it's not that the crypto is preventing the replay attack it's just that they maintain sequence numbers within their application layer between the two endpoints unfortunately the door controller connects a local controller at first I wanted to just initiate a new TCP connection to the door controller and say hey here's an unlock message unlock but you can't do that if the door controller is the one reaching out to the local controller in order to get to things and it kind of makes sense when you think about it because your door controller in some facilities maybe it's behind some sort of NAT the local controllers a little further away it makes sense for the most remote piece of the equipment to be the one reaching out to the progressively closer to the core pieces of equipment so if I couldn't initiate a new connection I needed to find another way turns out our spoofing still works thank you and you just man in the middle of the connection because if you can man in the middle of the connection you can decrypt and get those sequence numbers that you need in order to talk to both sides and in order to avoid the local controller saying hey I lost a connection to a door I started or applying to both sides that's what I was using the door message State for I just kept pulling the local controller yeah the doors still locked yeah the door still closed you're good to go but to the door controller I was telling it hey I have a remote door unlock from the administrative console please open the door for me and then at the end I dropped just plain drop the man in the middle I could have fixed up the TCP sequence numbers and like adjusted the windows and gotten it back to a same state but it turns out that on these networks these devices are so reliable that the error message of communications lost for a brief period time is completely ignored by anyone looking at it in fact in our installations those messages happen hundreds of times per day I'm not going to send someone to investigate every time a connection is lost it can happen from a loose cable it can happen from a quick drop in power at the site can happen from any number of factors and so no one's investigating Oh communication loss they came back 30 seconds later when it automatically did a reconnect so it turns out that you could just in in the middle with your encryption key and send it a message it says unlock the door and it unlocks the door for you so
this is basically what it looks like you just need access to the network between the door controller and the local controller and you can send an unlocked door one message and it will unlock door one now one interesting thing is when we first reported this to the vendor their first response was well yeah you shouldn't give attackers access to the network between the door controller and the local controller and I had to actually stop and think about how to respond to that for a second because I was like your product brochure says aes-256 if your premise is they can't get physical access why do you need the encryption in the first place and then I said and do you really think that all installations everywhere don't have the physical access to an attacker and they were like well yeah we you know you always want to put these on an isolated network and it should be completely internal to your site and all of these things and I said don't you also sell a security camera product that integrates with this and they're like yeah yeah we can we have security cameras said don't some customers put the security cameras on the outside of the building well yeah I was like and the security cameras talked to the network how well yeah but that should be on an isolated network that you then just bridge over the connection from the cameras into the controllers Network and I said do you really think your customers are setting it up that way or do you think they're just plugging everything into a switch saying hey it works and moving on right I mean I don't it could be maybe everyone is segmenting every device into their own land segment and all patch panels are carefully hidden behind well secured doors it was not marketing it was in fact engineering that I was talking to although you know there were also managers in the room so
so how do you go about fixing something like this right I'm not coming up here to tell you oh you know these things are all broken and it's hopeless and everything like that how do you actually go about fixing this in a way that makes the situation better right we tried to work with the vendor to get an improvement and my first suggestion was stop rolling your own crypto I mean I know you're using AES that's great but stop rolling your own implementation of that and use TLS and they were actually already linking to live SSL in order to get the AES functions to do the crypto so it wasn't like they didn't have it sitting around I was like okay use TLS and they come back alright we will make an updated version of the product and the updated version of the product will use TLS and I said great how are you gonna do key distribution and they said oh it's simple we'll distribute the keys in the firmware images we're still back at hard-coded keys so like why is this
such a such a thing right you can easily implement some proper crypto but key distribution is really the hard part of doing transport security on embedded devices right like these devices do not have your typical interface that you would have on your laptop on your desktop computer in fact many of them may not have host names how do you do a TLS certificate verification when I point it to right no one's gonna give me a certificate for an internal IP address rightfully so and at the same time I expect to be able to communicate with that device securely it also turns out they told us they couldn't fix the existing devices that were in place because they didn't have enough flash in order to have the entire TLS implementation present so I said they can only fix it in the next generation of device and obviously these devices should really be on an isolated network right we can't depend on some internet-based solution for our key distribution because I don't really want my door access controllers reaching out to the Internet to get their crypto material seems like I'm creating more problems so we started working with them and we started thinking internal even like how do you do these sort of things so some of the criteria that you need in order to do it correctly is ensuring that keys are not common across multiple installations and that devices need to only communicate with trusted partners and each individual message should have both confidentiality and integrity which means having a Mac of some sort or otherwise signing the messages and finally they really shouldn't be rolling their own crypto so coming up with this we came up with a few hypothetical solutions we weren't trying to redesign for them right we're not a consultancy just a user of their product but we also wanted the next version of the product to be something we could feel comfortable using so hypothetical one it's used TLS the vendor ships each device with a certificate and they trust all other devices signed by that vendor right strictly speaking I think maybe that's better than what we had but not by much and tacker can just go on eBay buy their own device extract the key and then they can man in the middle using the key they extracted from a device on ebay so this doesn't really get you into a much better situation than you have with just a hard-coded AES key so someone points out why couldn't you just generate a new key of boot time and say hey here's my new key well the problem is you still need some way to verify that that key belongs to the device you expect to talk to you write a newly generated key is fine but you need some sort of authentication to the key which is why we have CAS and the traditional PKI model is to say that that key is a real key if I just give you a random key every time then any in the middle can do it so one other proposal use TLS configure each device with a customer specific CA certificate and then the key material and the CA certificate on each device and the problem with the biggest problem with that is it becomes difficult at scale if you have to manually deploy a key and see a certificate on each individual device right a large installation may have thousands of these devices in their place think about how many access control doors your employer has right if you work for a large fortune 100 company there's gonna be you know anywhere from a couple of thousand to even tens of thousands of access controlled doors within your offices so in a third op option you could use TLS you can ship each device with a hardware at a station key that's baked into a secured chip and the device can sign a certificate request on the first first boot and then send it upstream to a central CA that's maintained on the same server that is actually making the authentication choices so you now have a route of trust that's in the same place as your database of card credentials and door access controls now this isn't perfect because it does require some additional setup it requires a little bit of additional hardware and for in the device at a station key and it does require that your network is trustworthy on first use but in reality it's a lot better than where you are and it's actually very similar to the SSH model right the first time you SSH into a new machine you get a prompt to accept the key and I'm sure we all very diligently go and check the fingerprint if the key on their remote server no the reality is if you're on a network that you don't think is being screwed with you say yes and then if it ever changes maybe you start to worry about how your network was additionally since the CA is sitting on the same host where your door access control database is sitting or on the same servers that are providing that information a compromised of your CA would have been a compromised of your door access control system anywhere so this puts the route of trust in the same place as your a Thor native source of data for it which results in possibly and the one of the best case scenarios that you can have while still not having to have user interfaces or individual configuration of the devices I don't make a claim that this is the best situation but we're hoping that this is a model that the vendors of devices like these might consider moving towards since there already is a central point on each Network for the communications right it's not fully distributed so I think it's important to note that software security matters for physical security systems right I think many of you coming to the IOT village don't need to be convinced of that particular case but it turns out that a lot of physical security vendors have so much expertise in terms of physical security right they'll tell you oh this lock is unsimilar this and we have a sensor on the back of the badge reader that will tell you if it's been pulled off the wall and all of these physical attacks but they don't look at the network layer because they still are in the mindset of the physical attacks that they've been protecting against for years and IP has just been shoehorned into these systems the industry could be doing so much more and I buyed the industry I mean both the physical security systems and customers customers who are aware of these security vulnerabilities are aware of these concerns can be applying pressure to the vendors to get testing to get their devices you know looked at by an independent security consultant and finding these bugs before they get to market before they get them installed and find ways to make them more resistant to network layer tampering but at the end of the day it's an ecosystem and it'll all depend upon what customers are asking for hopefully customers will be asking for secure systems since it is a physical security system but in our discussions with vendors it seems like very few customers seem to be committed to be caring about the network security aspects they just want something that's going to keep physical concerns at bay so any questions I'm happy to
whew there's also my Twitter handle my blog and a short link for this slide deck if you want to take another look at it I also have some IOT hacker stickers if anyone wants to come up after the talk you're welcome to some of those as well yes question so the question was do I expect some attestation from the server that the device is actually one of the vendors devices yes so that's why in this third scenario I said that the
device is shipped with a hardware attestation key and so I would say that the certificate requests for the first time use would be signed with that to at least show that the certificate is being issued to one of their devices obviously if a malicious attacker gets one of the devices and plants it on your network they might be able to get a key as well so it's not a perfect solution but it I think it raises the bar yes so I very vaguely familiar with it in this particular case the weak import I'm sorry I should repeat the question though question is how will the new OSD Pequot protocol improve compared to Wiegand and so the reality is it depends on the attack right there are certainly attacks that you've seen like ble key and things like that where they're cloning the badge numbers off of the Wiegand wires I don't know enough about OS DP to say whether or not that makes a dramatic improvement to those attacks to this particular attack it would have no effect because it's IP protocol between those two devices and it's their own proprietary protocol it's no longer Wiegand at that point it's just transporting the badge number as a single number but I do think moving away from a protocol that was designed for encoding magnetic bit flips is probably the right choice in 2018 [Music] [Music] so the question basically is is public key infrastructure the right way to go because public key infrastructure requires immense computing resources to perform the cryptographic calculations and so IOT devices can't handle that and for various reasons so and I think in this particular scenario the the device is in question and devices of this style a lot of the concerns that you mentioned in terms of battery life for example these are not battery powered devices they're all hardwired so battery life is not a concern and the microcontrollers that are present on them even on the smaller end are more than capable of doing a PKI handshake each time they set up a TCP connection right these devices don't have high volumes of connection they're not doing things that you know hundreds of connections at a time in fact if it wasn't for the occasional network comes failure on these devices they stay connected for days at a time between the two endpoints with a TCP connection additionally since this isn't part of a public PKI you could easily do it with elliptic curve cryptography which is dramatically easier on processors and much easier to do there so I'm I'm sure that there are other solutions as well right you said should we be looking for something new yeah absolutely but I'm not aware of anything new that would address the problem and in the correct fashion if cryptographers have something up their sleeves that they would like to share with me I'd love to learn about something else but this is the best approach that I'm aware of
right so the question is like how do you keep from spoofing a device in terms of having the the TPM chip well TPM do have unique keys burned into them at manufacturing time extracting those keys from those devices is supposed to be difficult the manufacturers make it very difficult it's not impossible but it dramatically increases the bar on an attacker and if you can start pulling secrets out of hardware secure elements there's probably a large number of other attacks that at opens you up to having that capability yeah I mean if someone if someone is able to start extracting RSA keys from TPM or secret keys from TPMS another thing they can do for example is completely subvert the route of trust for a number for like secure boot on a device if they can get your TP the encryption keys out or though it's a secure keys out of the TPM I mean that's that's what TPMS are designed to resist against is being able to spoof their identity right any other questions oh sorry by key device you mean the badges so one of the reasons that badge cloning is so possible is that doing proper cryptography so when I was asked earlier about low-power devices right that is the ultimate low-power devices your your procs card style badge has a microcontroller in it but that microcontroller is only powered by the inductive coupling between the door reader and the badge and you expect it to happen in something like a tenth of a second and so I've actually at conversations with designers if these chips I was like hey why isn't it just a private key in there and you do like an e CTSA signature then no one could ever a copy could clone a badge just by reading it right I mean ECDSA signatures are should be strong and he was like yeah we're dealing with processing power that's like 1% of what you would need to do an ECDSA signature so if you had an active badge that had a battery in it that would probably be feasible but then you have people locked out if their office when the battery dies so there's trade-offs to be sure I would love to see a solution where you basically have end-to-end cryptographic assurance all the way from your badge to the server that verifies it and back to the door yeah so the bridge told of Isis they actually use very similar technology to a procs card but most of what makes it chunkier is not in fact a battery at least in the ones I've opened up in California it's much much much larger antennas than what you have in the badge that it can do the longer-range read and of course the readers that are mounted over the highway for the bridge tolls are much much much more powerful readers than you have in it's also why you see if you go through a drive-in garage where you have to badge into the garage you notice the readers there are typically maybe a foot by a foot in size whereas the ones on the door molding or 2 inches by 3 inches and all of that size difference it's not so that you can see it more easily or something like that it's entirely so that you have a much bigger antenna and can have much more power coupling between the two devices giving you a longer read range alright I think I've just about run out my time if anyone wants to chat afterwards I'll be around for a little bit and thank you very much [Applause]