Return to Video

#rC3 - Exposure Notification Security

  • 0:00 - 0:17
    RC3 preroll music
  • 0:17 - 0:20
    Jiska: Hello, everyone, and welcome to my
    talk, which is about Bluetooth exposure
  • 0:20 - 0:25
    notification security. This talk could
    also be summarized as follows: So first of
  • 0:25 - 0:31
    all, exposure notifications as in the
    Google/Apple API are very secure and
  • 0:31 - 0:36
    battery friendly. And please, just use the
    Corona Warn App. This might be very
  • 0:36 - 0:39
    confusing to most of you, who are
    listening and know me since a while
  • 0:39 - 0:44
    because I have been working on Bluetooth
    exploitation in the past and always
  • 0:44 - 0:48
    thought everyone, like, Bluetooth is
    insecure. So you might wonder: How does
  • 0:48 - 0:53
    this align? Why am I now here telling you
    that Bluetooth exposure notifications are
  • 0:53 - 1:00
    secure? So well it's a pandemic, so
    instead of just criticizing solutions, we
  • 1:00 - 1:06
    should also look for solutions that work.
    So instead of ranting, work on something
  • 1:06 - 1:15
    that helps everyone! So the first question
    that many people asks are, do we even need
  • 1:15 - 1:22
    a smartphone app to fight a pandemic? What
    we can say, well, it's December exposure
  • 1:22 - 1:26
    notifications were introduced in June and
    we still have Corona, it still exists. So
  • 1:26 - 1:35
    it didn't help to fully fight them and
    probably it won't stop Corona. But let's
  • 1:35 - 1:41
    look at this from another perspective. So
    first of all, if you have an app and get
  • 1:41 - 1:46
    the warnings, we can do more accurate
    testing and that's very important because
  • 1:46 - 1:51
    even now we are still low on tests. We
    cannot test everyone. We only test people
  • 1:51 - 1:57
    with symptoms. And that's really an issue
    because people can, infect other people
  • 1:57 - 2:02
    prior to symptoms and they could even
    infect others without having symptoms or
  • 2:02 - 2:08
    they're asymptomatic cases. And these can
    be found with the Corona Warn App. And
  • 2:08 - 2:11
    also this can encourage manual contact
    tracing because official health
  • 2:11 - 2:17
    authorities, they are not able to make
    physical, manual contact tracing any more.
  • 2:17 - 2:23
    So you need to ask your friends and so on
    if your app turns red, and then you might
  • 2:23 - 2:28
    find cases, even if they forgot to tell
    you. Of course, this all doesn't replace
  • 2:28 - 2:34
    washing your hands, wearing a mask,
    physically distancing and so on. So, of
  • 2:34 - 2:40
    course, you still need to take these
    measures. But even if you just inform a
  • 2:40 - 2:45
    few people, every prevented infection
    actually saves lives. So it's very
  • 2:45 - 2:53
    important to have an app like this. And
    the next question is, well, is there
  • 2:53 - 2:57
    something better than Bluetooth? So if we
    want to look for a solution to build an
  • 2:57 - 3:03
    app that supports exposure notifications
    and prevent infections, how could we build
  • 3:03 - 3:10
    it? So we actually need something that
    somehow measures proximity or location and
  • 3:10 - 3:14
    in a smartphone, we have various
    technologies that support that. So there
  • 3:14 - 3:20
    is GPS, there's Bluetooth, there's LTE and
    5G, there's Wi-Fi, there is Ultra-
  • 3:20 - 3:24
    wideband, you probably never heard of
    this. There's audio. There is a camera.
  • 3:24 - 3:31
    You could use all of this. And the reason
    why you can use this to measure a distance
  • 3:31 - 3:37
    or a direction is that on the physical
    layer you have a wave form. And this wave
  • 3:37 - 3:42
    form, first of all, has an amplitude and
    with the distance, this amplitude gets
  • 3:42 - 3:45
    lower. So this also means that the signal
    strength is lower and you also have a
  • 3:45 - 3:50
    phase that is changing with the distance.
    So these are properties that you can
  • 3:50 - 3:54
    measure on the physical layer, on a raw
    wave form. And some of this information is
  • 3:54 - 4:00
    also sent to upper layers. And the most
    obvious one is the signal strength, so
  • 4:00 - 4:04
    it's a physical layer property that you
    can measure, and it's also sent to the
  • 4:04 - 4:10
    upper layers on most protocols for simple
    things like determining how strong the WiFi
  • 4:10 - 4:15
    is, so that your device can actually
    pick the strongest Wi-Fi access point and
  • 4:15 - 4:19
    so on. So the signal strength is very
    essential and sent to upper layers in most
  • 4:19 - 4:25
    protocols. You could actually even do a
    precise distance measurement, but for
  • 4:25 - 4:30
    this, you need the raw wave form and
    that's not supported by most chips. There
  • 4:30 - 4:34
    are a few chips that can do that. So for
    the precise distance measurement, you
  • 4:34 - 4:39
    actually need to send a signal and send it
    back and measure the round trip time of
  • 4:39 - 4:44
    this signal. And this is, for example,
    done to determine if your Apple Watch can
  • 4:44 - 4:49
    unlock your MacBook. And the third option
    is that you can even measure a signal
  • 4:49 - 4:54
    direction. This actually needs multiple
    antennas to do some sort of triangulation
  • 4:54 - 4:59
    of the signal. And this is not supported
    by most chips because you not just need
  • 4:59 - 5:04
    the support in the chip, but also the
    multiple antennas. But with this, you can,
  • 5:04 - 5:09
    for example, do things like on some
    iPhones, you'll get some AirDrop direction
  • 5:09 - 5:14
    of the other iPhone and so on, so you can
    have a direction shown on your device, of
  • 5:14 - 5:22
    a signal. When it comes to location, the
    most obvious choice for many people, or
  • 5:22 - 5:27
    the intuitive choice, would be GPS and
    GPS, well, the signals are sent by
  • 5:27 - 5:32
    satellites and they orbit earth at more
    than 20.000 km, so they are, like, very,
  • 5:32 - 5:37
    very distanced. And until the signal
    arrives on your smartphone, there is a lot
  • 5:37 - 5:42
    of attenuation. So even if there are,
    like, just a few buildings or if you are
  • 5:42 - 5:46
    indoors or something, but already a few
    buildings are sufficient to make the
  • 5:46 - 5:52
    location imprecise and indoors, it doesn't
    work at all. But indoors we have the
  • 5:52 - 6:01
    highest risk of infections. So GPS is not
    really helpful here. The next option would
  • 6:01 - 6:09
    be signals from LTE, 5G and so on. So here
    you have some senders and you actually
  • 6:09 - 6:14
    change cells with your smartphone. So,
    here we have one cell and while you move,
  • 6:14 - 6:19
    you move to another cell and this is some
    movement that you do and you can measure
  • 6:19 - 6:25
    the changes between the cells. And this
    actually has been used by phone providers
  • 6:25 - 6:30
    in Germany to determine how effective the
    lockdown rules are. So with this, you can
  • 6:30 - 6:37
    actually see if people move more or less
    than prior to the pandemic and so on, or
  • 6:37 - 6:41
    how effective the rules are and so on.
    These are not very precise statistics, so
  • 6:41 - 6:50
    this is nice to have those very broad
    statistic for a lot of people, but it's
  • 6:50 - 7:00
    not useful to determine who you were
    meeting. And another option is Wi-Fi, but
  • 7:00 - 7:05
    for Wi-Fi you have another issue. So Wi-
    Fis depend on access points and so on, and
  • 7:05 - 7:10
    you can scan for access points. And of
    course, most smartphones also support,
  • 7:10 - 7:14
    that you spawn your own Wi-Fi access
    point. and then you could scan for this,
  • 7:14 - 7:18
    but then you can no longer use your Wi-Fi
    because you can only join one Wi-Fi or
  • 7:18 - 7:24
    spawn one Wi-Fi access point and so on.
    And this really doesn't work. There are
  • 7:24 - 7:28
    some vendor specific additions that would
    allow distance measurement, but it's not
  • 7:28 - 7:34
    in most devices, it's not accessible
    through APIs and stuff like this. So you
  • 7:34 - 7:41
    cannot use Wi-Fi because of how it works
    and how it is build into smartphones. The
  • 7:41 - 7:45
    best option for precise measurement is
    audio, because even if you don't have
  • 7:45 - 7:53
    access to the chip or any API, what you
    have here is that you have a sender or
  • 7:53 - 7:59
    like a speaker and microphone and they
    send a wave and you can measure this wave.
  • 7:59 - 8:04
    So even without any lower layer access to
    some firmware, to some chip, you can have
  • 8:04 - 8:09
    this very precise measurement. But here
    the issue is that it means that you need
  • 8:09 - 8:14
    access to the microphone. So an app would
    need to run and foreground with a
  • 8:14 - 8:18
    microphone all the time. This drains
    battery and even worse, it means that you
  • 8:18 - 8:22
    have a permanent spy in your pocket. So
    you have a governmental app that would
  • 8:22 - 8:28
    listen to your microphone all the time.
    And many people don't want this. Then
  • 8:28 - 8:32
    there is some option that you probably
    have never heard of, Ultra-wideband, so
  • 8:32 - 8:36
    that's coming to the newest generation of
    iPhones and so far it's not used for many
  • 8:36 - 8:41
    features. It's just something that can
    also determine the direction of signal
  • 8:41 - 8:46
    because it's using multiple antennas and,
    so it can show you in which direction
  • 8:46 - 8:51
    another devices is. But since it's only in
    a few devices, it's nothing that's useful
  • 8:51 - 8:56
    for the general public. So it's a nice
    feature, but we are just a few years too
  • 8:56 - 9:03
    early for it. And of course, you could use
    a camera similar to the microphones, you
  • 9:03 - 9:08
    could, of course, record everything with
    the camera, but that's probably not the
  • 9:08 - 9:14
    solution that you want. So more likely you
    could actually use it to lock into
  • 9:14 - 9:19
    locations. So you scan a QR code and then
    register that you are in a restaurant or
  • 9:19 - 9:24
    that you are meeting friends. So this is
    what the camera ideally should be used for
  • 9:24 - 9:32
    and that would be a nice addition to the
    warning apps. And what's left, well, there
  • 9:32 - 9:38
    is Bluetooth. Bluetooth actually sends
    signals at 2.4 GHz, like Wi-Fi , and 2.4
  • 9:38 - 9:45
    GHz has a very big issue because it's
    attenuated by water and humans are 60%
  • 9:45 - 9:52
    water. So the measurement is a bit
    imprecise. But I mean, 40% of the human
  • 9:52 - 9:56
    are stupidity. And that's also an issue
    because humans are not using the Corona
  • 9:56 - 10:03
    Warn App at all. That's even worse. And
    what else is there? The next issue is that
  • 10:03 - 10:08
    the chips vary and the antenna position
    varies and so on. So you actually have the
  • 10:08 - 10:13
    issue that the measurements are not the
    same on each smartphone model. So it might
  • 10:13 - 10:19
    be the same signal, but different
    measurement. And for this first issue with
  • 10:19 - 10:23
    the different measurements of the same
    signal, we already have something that's
  • 10:23 - 10:29
    built into the API, the official
    Google/Apple API, and they include the
  • 10:29 - 10:37
    transmit power per device model and so on,
    which is a slight risk for privacy. But
  • 10:37 - 10:45
    overall, it has a very good compensation
    here. So, they said that this is better to
  • 10:45 - 10:49
    use and have a little bit less privacy.
    Something else that you could use are
  • 10:49 - 10:55
    active data connections over time to track
    the average signal strength. But that's
  • 10:55 - 10:59
    worse because the active data connection
    means that you have data that's being
  • 10:59 - 11:06
    exchanged between two devices and this is
    a risk for exploitations. So exploits need
  • 11:06 - 11:12
    some exchange of data and this would be a
    risk for security. And another thing that
  • 11:12 - 11:17
    you could add is the accelerometer. So
    depending on how you hold your smartphone,
  • 11:17 - 11:20
    you can actually determine, by the
    accelerometer, if it's in your hand, in
  • 11:20 - 11:25
    your pocket and so on, and then compensate
    for this in the measurements. But the
  • 11:25 - 11:31
    issue here is that the accelerometer also
    is able to determine if you are running,
  • 11:31 - 11:36
    walking, how many steps you're walking and
    so on. So it's a huge privacy impact to
  • 11:36 - 11:43
    access the accelerometer. And last but not
    least, there's the angle of arrival, and
  • 11:43 - 11:48
    that's something that's supported since
    Bluetooth 5.1 but it's an optional feature
  • 11:48 - 11:52
    in the Bluetooth specification, so no
    smartphone has it yet. So you cannot
  • 11:52 - 11:59
    actually do a specific measurement of the
    angle of another device. So that's pretty
  • 11:59 - 12:05
    sad. And, well. So everything that
    improves those measurements on Bluetooth
  • 12:05 - 12:12
    is always at the cost of privacy, security
    and battery life. So just considering how
  • 12:12 - 12:19
    it's currently done in the API, it's
    pretty good. And to sum this technology
  • 12:19 - 12:24
    rant a bit up, well. So even though
    Bluetooth is not perfect, Bluetooth Low
  • 12:24 - 12:28
    Energy, it's really the best technology
    that we have in all smartphones or all
  • 12:28 - 12:34
    recent smartphones. And with this, we can
    build exposure notifications. So, yeah,
  • 12:34 - 12:42
    even though Bluetooth might not be
    optimal, it is still a winner. Yeah, yeah,
  • 12:42 - 12:47
    yeah, I know Bluetooth is dangerous and so
    on, so let's discuss this a little bit. So
  • 12:47 - 12:53
    actually during 2020, a lot of newspapers
    were trying to reach me and said, like:
  • 12:53 - 12:57
    "Hey, jiska, you have been working on
    Bluetooth security, so please, please tell
  • 12:57 - 13:01
    us how bad the current state of Bluetooth
    security is." And I was like, yeah, I
  • 13:01 - 13:06
    don't really want to tell this because,
    you know, Bluetooth is a wireless protocol
  • 13:06 - 13:12
    that transmits data and that has certain
    risks, but so has everything else. So,
  • 13:12 - 13:15
    yeah. And then they didn't print this. I
    mean, it's really not a nice headline to
  • 13:15 - 13:21
    print, "Bluetooth is a wireless protocol
    that transmits data." Yeah. And then they
  • 13:21 - 13:26
    were like: "You know, I'm not using the
    exposure notifications because I'm using
  • 13:26 - 13:31
    an outdated smartphone that does no longer
    receive security updates." And then I'm
  • 13:31 - 13:35
    like, huh yeah. So I mean, no security
    updates - that's not just an issue for
  • 13:35 - 13:39
    Bluetooth. That's an issue for everything,
    like if you browse unicorn pictures on the
  • 13:39 - 13:46
    Internet or receive mail, So I don't know
    what, maybe just get a new smartphone if
  • 13:46 - 13:51
    you're very concerned about the data on
    your smartphone. And also something that
  • 13:51 - 13:55
    you shouldn't do to a journalist when they
    ask you this, is tell them: "So you have
  • 13:55 - 13:59
    an outdated smartphone? Are you just
    calling from a number that belongs to the
  • 13:59 - 14:07
    smartphone?" But, yeah. So just don't
    discuss this because it's a very general
  • 14:07 - 14:14
    issue that's not specific to Bluetooth.
    And something that's a bit more specific
  • 14:14 - 14:20
    to Bluetooth is that, well, you can build
    worm swifties. So a device can be a
  • 14:20 - 14:27
    master or a slave in the Bluetooth
    terminology. And so a master can connect
  • 14:27 - 14:32
    to slaves, and a smartphone can switch
    roles, which means that it can receive a
  • 14:32 - 14:36
    worm and then become the master and
    transmit of worm to another slave and the
  • 14:36 - 14:42
    slave then becomes a master and so on. So
    it's wormable. But to have a very good
  • 14:42 - 14:47
    worm, you would actually need an exploit
    that runs on a recent iOS and a recent
  • 14:47 - 14:53
    Android version and that is very reliable,
    so it should be a very good exploit on all
  • 14:53 - 14:58
    platforms. And if someone had such an
    exploit, they would probably not use it to
  • 14:58 - 15:03
    destroy exposure notifications, but they
    would sell it for the price that is
  • 15:03 - 15:07
    currently available on the market. The
    highest price, of course, because probably
  • 15:07 - 15:13
    you don't have that many ethical concerns,
    instead of reporting it. But, yeah. So
  • 15:13 - 15:20
    that would be more of the scenario here.
    Then also people say: "I turn my Bluetooth
  • 15:20 - 15:24
    off because Bluetooth drains battery".
    But, you know, Bluetooth doesn't drain a
  • 15:24 - 15:28
    lot of battery, especially Bluetooth Low
    Energy. So Bluetooth Low Energy is a
  • 15:28 - 15:36
    technology that can power even small
    devices like item finders of this size. So
  • 15:36 - 15:42
    if you have a battery, button cell of this
    size and then have like a device, slightly
  • 15:42 - 15:47
    larger, like a Bluetooth Finder, of this
    size, they can run with this button cell
  • 15:47 - 15:51
    for a year. And you charge your smartphone
    daily, your smartphone has much more
  • 15:51 - 15:57
    battery capacity than just one button
    cell. So, yeah, go for it. It really
  • 15:57 - 16:02
    doesn't drain battery, especially because
    you also have combo chips and if you have
  • 16:02 - 16:08
    Wi-Fi enabled, then Bluetooth really
    doesn't add anything to this. Another
  • 16:08 - 16:13
    argument might be that Google and Apple
    are always stealing our data, and if they
  • 16:13 - 16:18
    now do the contact tracing, this means
    that they are stealing data. But in fact,
  • 16:18 - 16:23
    the exposure notification API was renamed
    because it really is just about exposure
  • 16:23 - 16:28
    notifications. It's not about a contact
    log. And this means that this API is not
  • 16:28 - 16:35
    collecting any data about your contact
    trace and well, it's good and bad in terms
  • 16:35 - 16:40
    of, they are preventing a centralized
    collection by everyone. So not just by
  • 16:40 - 16:44
    health authorities, they just prevent it
    by everyone and including themselves. So
  • 16:44 - 16:53
    there is just no data collection. So you
    cannot complain about this. So, yeah,
  • 16:53 - 16:59
    after saying this, you might ask me if I
    had now just said like that Bluetooth is
  • 16:59 - 17:04
    not dangerous at all. But, you know,
    Bluetooth is still a wireless protocol
  • 17:04 - 17:15
    that transmits data. So, yeah, maybe it's
    still somewhat dangerous. So if you look
  • 17:15 - 17:21
    at the Apple ecosystem, what you have is a
    feature set called Continuity Framework
  • 17:21 - 17:26
    and this does a lot of things like some
    copy-paste AirDrop hand-off, whatsoever.
  • 17:26 - 17:33
    So data that's being exchanged. And all of
    this continuity part here, it all works
  • 17:33 - 17:41
    with BLE advertisements and then actually
    Wi-Fi or AWDL for the data transfer. So
  • 17:41 - 17:46
    you have a lot of BLE advertisements going
    on if you already are using iOS and other
  • 17:46 - 17:51
    Apple devices. And exposure notifications
    - they really are just a tiny additional
  • 17:51 - 17:55
    thing here. So it's just yet another
    feature that's based on BLE
  • 17:55 - 18:04
    advertisements. So it's nothing that adds
    a lot. And you also need to know that the
  • 18:04 - 18:08
    exposure notifications don't have a lot of
    logic, so you just receive them, you don't
  • 18:08 - 18:13
    answer to them and so on. So it's, really,
    a very harmless feature on top, compared
  • 18:13 - 18:19
    to the other services running. Now, let's
    look into an Android example, which is a
  • 18:19 - 18:26
    recent Bluetooth exploit. So bugs like
    this exist, and this is not just specific
  • 18:26 - 18:31
    to Android, it can also be on iOS and it's
    also not specific to Bluetooth because we
  • 18:31 - 18:36
    have bugs all the time. So if you are
    using software, if you are not updating
  • 18:36 - 18:40
    it, there might be bugs in it or there
    might also be bugs in it that have not
  • 18:40 - 18:47
    been seen for a while. So despite they
    should have been fixed and so on. So this
  • 18:47 - 18:52
    just exists whenever you're using
    software. And also those bugs often depend
  • 18:52 - 18:57
    on certain hardware and software versions.
    So, for example, this exploit only works
  • 18:57 - 19:03
    on Android 9 and older because it requires
    a very specific implementation of memcopy,
  • 19:03 - 19:08
    because the memcopy is called with an
    length argument of -2, and it has
  • 19:08 - 19:14
    different behavior on different systems.
    And last but not least what this exploit
  • 19:14 - 19:20
    actually needs to run for something like 2
    min because you need to bypass ASLR over
  • 19:20 - 19:25
    of the air. So you need to be in proximity
    of a vulnerable device for a while if you
  • 19:25 - 19:32
    are an attacker. And now people say:
    "Yeah, but it's special because this kind
  • 19:32 - 19:36
    of bug, it's wormable". Yeah, that's
    true. So you could build a Bluetooth worm
  • 19:36 - 19:41
    with this, but what does it look like? So
    first of all, the devices are losing
  • 19:41 - 19:47
    connection. So you don't have a full mesh,
    but you have like some connections here
  • 19:47 - 19:51
    and there and you have a worm spreading
    somewhere and so on and so forth. But the
  • 19:51 - 19:55
    attacker actually needs some control
    server. So no matter what the attacker
  • 19:55 - 20:01
    wants to achieve, like steal data or do
    some Bitcoin mining or something, in the
  • 20:01 - 20:07
    end you need to have some feedback and
    control server in the Internet to have a
  • 20:07 - 20:11
    communication or also if something goes
    wrong with your exploit to stop it or
  • 20:11 - 20:16
    something, you need this back channel,
    despite you have a wireless channel
  • 20:16 - 20:21
    because your wireless channel is not
    permanent. And the next challenge here is
  • 20:21 - 20:29
    that your exploit needs to be very
    reliable, so it means that if you actually
  • 20:29 - 20:32
    produce a crash and if you have a worm
    that spreads very fast and that spreads a
  • 20:32 - 20:37
    lot, then you have the problem that if
    it's not 100% reliable, you would get
  • 20:37 - 20:44
    crashes and that are reported to Apple or
    to Google. And this is an issue because
  • 20:44 - 20:48
    once a bug is detected, it means that
    Apple and Google will update their
  • 20:48 - 20:54
    operating system and your bug is gone. So
    all your exploit development was just for
  • 20:54 - 21:00
    nothing, your exploit is gone. And well,
    that actually means that if an attacker
  • 21:00 - 21:06
    would want to build a worm, they would
    probably just use some outdated bug. And
  • 21:06 - 21:12
    as I said, bugs happen so they are there
    every few months or years, it depends. You
  • 21:12 - 21:19
    would have a bug that works for a worm and
    then the attacker does not have the risk
  • 21:19 - 21:26
    of losing a very, like, unique bug that is
    worth a lot of money if they use an old
  • 21:26 - 21:30
    one. But it also means that all the
    devices that get updates are safe from
  • 21:30 - 21:36
    this worm. So it really depends on what
    the attacker wants to do. So what I
  • 21:36 - 21:41
    think is more likely so instead of
    building a worm - what are attack
  • 21:41 - 21:46
    scenarios? Well, if you think about
    Bluetooth exploits, the worm needs a lot
  • 21:46 - 21:52
    of reliability and so on. And you have
    this risk of losing the exploit. So
  • 21:52 - 21:56
    probably the attacks are a bit more
    targeted and require the physical
  • 21:56 - 22:02
    proximity of those targets. So stuff that
    I would say is very realistic would be
  • 22:02 - 22:08
    like if you have some airport security
    check or if, like an attacker is close to
  • 22:08 - 22:12
    certain buildings, like company buildings
    or your home or something, to steal
  • 22:12 - 22:17
    certain secrets or also from the
    government, if there are protests and the
  • 22:17 - 22:24
    government does not want them or wants the
    identities of the protesters or something,
  • 22:24 - 22:35
    this would be an option. But the worm, as
    I said, is, yeah, a bit, let's say, not so
  • 22:35 - 22:42
    plausible. And the next thing is so
    exploit development means that if you want
  • 22:42 - 22:50
    to develop and exploit for recent iOS and
    Android, then this is a lot of work and
  • 22:50 - 22:55
    well, your enemy might be able to afford
    this. And in this case, they can also use
  • 22:55 - 23:00
    it multiple times for as long as the bug
    does not leak and it's not fixed, they can
  • 23:00 - 23:05
    reuse to exploit. So it's a one time
    development cost. But if you think you
  • 23:05 - 23:09
    have enemies like this, then probably use
    a separate smartphone for exposure
  • 23:09 - 23:15
    notifications and keep your smartphone up
    to date and so on. Or if you are very,
  • 23:15 - 23:19
    very, very afraid of attacks and maybe just
    don't use a smartphone because Bluetooth
  • 23:19 - 23:24
    is really not the only way to hijack your
    smartphone. So you could still be attacked
  • 23:24 - 23:29
    just by a messengers, browsers, other
    wireless technologies, like LTE, and so
  • 23:29 - 23:34
    on. So it's just a risk that you have and
    that happens. And that's not specific to
  • 23:34 - 23:43
    Bluetooth. Anyway, let's go to a few
    implementation specific details, so if you
  • 23:43 - 23:48
    want to understand the exploitation
    background and why I think that the
  • 23:48 - 23:55
    Bluetooth Exposure Notification API, as it
    is, is very secure. So first of all, the
  • 23:55 - 24:01
    API does Bluetooth address randomization,
    so that means these addresses are
  • 24:01 - 24:06
    randomized and not connectable and you
    cannot connect to them as an attacker. And
  • 24:06 - 24:11
    also, there is no feedback channel because
    of this non-connectable property. And it
  • 24:11 - 24:17
    means that usually your smartphone is
    configured in a way that it doesn't
  • 24:17 - 24:23
    announce any connectable addresses, it
    only has these random addresses. And this
  • 24:23 - 24:26
    is really hard for exploitations. So you
    need to know the correct address of a
  • 24:26 - 24:32
    smartphone to send an exploit to it. And
    it's not send over the air. So you need to
  • 24:32 - 24:36
    decode packets, for example, if you're in
    parallel listening to music or something,
  • 24:36 - 24:43
    you could extract the address from this,
    but it's very hard to achieve this. And
  • 24:43 - 24:48
    another part is, that especially Apple is
    tremendously restricting their Bluetooth
  • 24:48 - 24:55
    interfaces. So smartphone apps cannot use
    Bluetooth for arbitrary features that are
  • 24:55 - 25:03
    available within the Bluetooth
    specification. And this means, that this
  • 25:03 - 25:09
    is good for your privacy. So, for example,
    it's hard to build something like a spy in
  • 25:09 - 25:16
    your pocket on iOS because there it's hard
    to run an app in the background that does
  • 25:16 - 25:22
    all the tracking via Bluetooth and so on.
    And the other way around it means that if
  • 25:22 - 25:26
    there are apps that do exposure
    notifications or contact tracing and they
  • 25:26 - 25:34
    are not based on the official API,
    actually these apps are very exploitable
  • 25:34 - 25:41
    because they use active connections. They
    run in the foreground. They actually are
  • 25:41 - 25:45
    logging stuff that should not be logged,
    so I probably don't do this and don't
  • 25:45 - 25:54
    trust those apps that are not using the
    API. Another issue might be privacy. So
  • 25:54 - 25:59
    first of all, there's a random identifier
    that stays the same for a while, but as I
  • 25:59 - 26:03
    said, on iOS you have the Continuity
    framework and it does the same, so at
  • 26:03 - 26:07
    least on Apple devices this really doesn't
    make a big difference. And if you think a
  • 26:07 - 26:11
    bit broader than Apple. Well, first of all,
    there's the signal strength and if you
  • 26:11 - 26:17
    compare this like to other technologies
    that are wireless, like Wi-Fi and LTE,
  • 26:17 - 26:22
    there you also have signals with a signal
    strength and maybe changing addresses and
  • 26:22 - 26:28
    so on. You can always triangulate signals.
    So if you don't want to be tracked, you
  • 26:28 - 26:38
    would also need to disable Wi-Fi and LTE.
    Another very important part about the
  • 26:38 - 26:42
    security assumptions is the server
    infrastructure, so there are two types of
  • 26:42 - 26:47
    server infrastructure and first of all,
    you have one for the centralized approach,
  • 26:47 - 26:50
    which is also known as contact tracing,
    and in the centralized approach the server
  • 26:50 - 26:55
    knows everything. So the server knows who
    was in contact with whom and for how long.
  • 26:55 - 27:00
    So, for example, Alice met Bob for 15 min,
    but also Alice met 10 other people on
  • 27:00 - 27:09
    Tuesday or something so that they actually
    have a record log of who met whom. And now the
  • 27:09 - 27:14
    server can actually tell specific people
    after someone got a positive test and so
  • 27:14 - 27:20
    on, for how long this was, the server can
    still censor some of the information it
  • 27:20 - 27:27
    sends out to specific persons, but it has
    a lot of information internally. So this
  • 27:27 - 27:31
    means if this server is run by some
    governmental health authority, that all
  • 27:31 - 27:39
    the users have to trust this authority, a
    lot, with their contact history. And the
  • 27:39 - 27:45
    other approach are decentralized exposure
    notifications, so the server has a list of
  • 27:45 - 27:52
    pseudonyms and positively tested users,
    but these are just pseudonyms, not the
  • 27:52 - 27:56
    exact times and exposures. And everyone
    can download this list and compare it to a
  • 27:56 - 28:00
    local list. So you just have a local list
    on your smartphone of who you met. And you
  • 28:00 - 28:06
    can compare the lists with pseudonyms that
    are on the server. And this means that
  • 28:06 - 28:12
    everyone could even opt-out to publish
    these pseudonyms. And you don't share your
  • 28:12 - 28:19
    list to anyone. So why is this good or
    bad? Well, the governmental health
  • 28:19 - 28:24
    authorities don't get any contact tracing
    info in the decentralized approach, and
  • 28:24 - 28:28
    this might be an issue because this means
    that the government does not have any
  • 28:28 - 28:32
    statistics about spreaders or
    effectiveness of the app. They cannot
  • 28:32 - 28:37
    measure how much the app actually helped.
    They cannot measure how many infections
  • 28:37 - 28:41
    were prevented by telling people to go
    into quarantine or to get a test and so
  • 28:41 - 28:49
    on. But on the other hand, it means nobody
    is getting this data. So neither Apple nor
  • 28:49 - 28:53
    Google nor governments, nobody is getting
    the data and there is no gain from
  • 28:53 - 28:58
    attacking the servers because they don't
    have any private information. And there's
  • 28:58 - 29:03
    also no privacy impact from using the app.
    And in the end, if you get a positive
  • 29:03 - 29:08
    test, even then you can choose to not
    share the result if you think it's an
  • 29:08 - 29:14
    issue to disclose your pseudonyms. And I
    mean, ideally, many people should share
  • 29:14 - 29:23
    their result, but you don't have to. And I
    want to show you a few attacks on exposure
  • 29:23 - 29:27
    notifications, because some people said,
    like exposure notifications are very,
  • 29:27 - 29:33
    very, very insecure. So let's look into
    attacks that have been publicly discussed
  • 29:33 - 29:38
    on those exposure notifications as they are
    implemented now. And please note that many
  • 29:38 - 29:43
    of these attacks are not specific to
    Bluetooth, but they are specific to
  • 29:43 - 29:49
    everything that's somehow wireless and
    somehow a notification. So let's look.
  • 29:49 - 29:54
    Let's take a look. So the time machine
    attack. This one is quite interesting. The
  • 29:54 - 29:59
    assumption here is that someone can change
    the time on your smartphone and then
  • 29:59 - 30:07
    replay outdated tokens, so that you would
    think, like you met pseudonyms in the past
  • 30:07 - 30:11
    that were already known to be tested
    positive and because your smartphone also
  • 30:11 - 30:16
    is in the past, it would accept those
    tokens and log them and then if you
  • 30:16 - 30:22
    compare them to the server later on, you
    think that you were positive, in contact
  • 30:22 - 30:27
    with positive users and so on. But please
    note that spoofing time is very, very
  • 30:27 - 30:32
    hard. So if someone can spoof time, it
    means they can also break other things
  • 30:32 - 30:36
    like TLS. And I mean, if I had a time
    machine and I would just travel back to a
  • 30:36 - 30:44
    time prior to 2020 or something, instead
    of faking a few exposure notifications.
  • 30:44 - 30:51
    The next attack is the wormhole attack. So
    imagine that like this one would be one
  • 30:51 - 30:55
    shopping center, then another shopping
    center and maybe up there a police station
  • 30:55 - 31:00
    or something like this. How does that
    work? Well, if you wormhole them and put
  • 31:00 - 31:08
    them together, then the chance of getting
    positive exposure notification in the end
  • 31:08 - 31:17
    is very high. So you increase the chance
    of having positive exposure. And this
  • 31:17 - 31:24
    exposure, of course, was not real. So it's
    forwarded exposure. And because of this,
  • 31:24 - 31:28
    in the worst case, you would do more
    physical distancing, more testing, maybe
  • 31:28 - 31:34
    you also start to distrust the app a
    little bit, but it doesn't really harm the
  • 31:34 - 31:38
    overall system. So the amount of record on
    the server with the positive tests, it's
  • 31:38 - 31:44
    not increased because, only confirmed
    positive cases are uploaded to the
  • 31:44 - 31:49
    pseudonym list and those who are just here
    and get a notification are not uploaded.
  • 31:49 - 31:53
    And also to have such a deployment so to
    have this wormhole and the wormhole that
  • 31:53 - 31:59
    scales, you need a lot of devices that
    forward the notifications and in public
  • 31:59 - 32:06
    spaces so it's not that easy to implement
    this. The last attack is the identity
  • 32:06 - 32:10
    tracking attack, so let's say you have
    those pseudonyms. The pseudonyms, they
  • 32:10 - 32:15
    change over time and you are moving
    through a city and there are multiple
  • 32:15 - 32:20
    devices that are observing your pseudonym
    changes. So, of course, you can then start
  • 32:20 - 32:26
    tracking users. This, again, requires a
    very large scale installation. And the
  • 32:26 - 32:31
    issue is also that if you are scared of
    this type of attack, then you would also
  • 32:31 - 32:35
    need to disable Wi-Fi and LTE and so on,
    because you can always triangulate
  • 32:35 - 32:42
    signals. So ideally, if you don't want to
    be tracked, turn off wireless technology,
  • 32:42 - 32:49
    this is really not specific to Bluetooth
    at all. So, yeah, all those attacks, they
  • 32:49 - 32:56
    are valid, but to deploy them, like, to
    have records of exposure notifications
  • 32:56 - 33:03
    that you can then replay with time travel
    or a wormhole or also some tracing of IDs,
  • 33:03 - 33:07
    you really need a large scale installation
    of something like Raspberry Pis throughout
  • 33:07 - 33:13
    a city and many, many, many devices. So
    this would also work in any other wireless
  • 33:13 - 33:18
    ecosystem.
    But OK, but if you would roll out such an
  • 33:18 - 33:23
    installation, also, keep in mind that you
    could instead just deploy something like a
  • 33:23 - 33:29
    lot of devices that have microphones or
    cameras and Wi-Fi and so on and track a
  • 33:29 - 33:34
    lot of other things. This needs to happen
    in public spaces, so I don't know, next to
  • 33:34 - 33:40
    bus stations, shopping centers and so on.
    And well, if you have such an
  • 33:40 - 33:46
    installation, then really just tampering
    with exposure notifications of Bluetooth
  • 33:46 - 33:51
    is not your main concern. The sad reality
    might actually be that we already have a
  • 33:51 - 33:56
    lot of surveillance everywhere, so we have
    a lot of cameras in public spaces. So this
  • 33:56 - 34:02
    is not the part that I would be afraid of.
    I mean, I would be afraid of public
  • 34:02 - 34:10
    surveillance, obviously, but not about
    Bluetooth surveillance in particular. So
  • 34:10 - 34:14
    let me conclude my talk. The BLE
    advertisements are really the most
  • 34:14 - 34:18
    suitable technology that we have in a
    smartphone to implement exposure
  • 34:18 - 34:24
    notifications, and they are available on
    recent smartphones, on iOS and Android.
  • 34:24 - 34:29
    They are very secure, privacy preserving,
    battery friendly, and also scalable. And,
  • 34:29 - 34:33
    keep in mind, every prevented infection
    saves lives and also prevents long term
  • 34:33 - 34:42
    disease. So this is really a thing to use,
    even if it does not work 100%. And with
  • 34:42 - 34:47
    this, let's start the Q&A and discuss
    whatever you like, Bluetooth worms and so
  • 34:47 - 34:55
    on. Thanks for listening.
    Herald: All right, thank you, jiska, for
  • 34:55 - 34:59
    your talk. I hope you have time for some
    Q&A.
  • 34:59 - 35:06
    J: Yeah, let's go.
    H: Awesome.
  • 35:06 - 35:12
    J: Oh, I think that was Ollies
    Internet connection, was it? Yeah. So I
  • 35:12 - 35:15
    might just decide on my own until he
    reconnects. Ah, here you are!
  • 35:15 - 35:21
    H: I'm so sorry. The question was why
    would the angle of arrival be interesting
  • 35:21 - 35:26
    for an attacker or
    J: Not for, for an attacker. But like from
  • 35:26 - 35:32
    the technology, it would be interesting to
    have it in Bluetooth because then you
  • 35:32 - 35:37
    could do some direction estimation. And I
    mean, if people move, you could also get a
  • 35:37 - 35:43
    direction and maybe location via this or
    assist this. But yeah, I mean, it's not in
  • 35:43 - 35:48
    any chip yet except from some evaluation
    kits.
  • 35:48 - 35:55
    H: All right. Thank you. Is there any
    studies that proves or disproves the
  • 35:55 - 36:00
    efficiency of contract tracing apps in
    general? I mean, like the use case?
  • 36:00 - 36:06
    J: I mean, the issue is because we have
    the exposure notification framework that
  • 36:06 - 36:12
    we do not have any statistics. So the good
    and the bad thing about privacy is that we
  • 36:12 - 36:18
    cannot have such a study except from if
    people would provide their data in, I
  • 36:18 - 36:22
    don't know, a questionnaire or something.
    But at least I know people who have been
  • 36:22 - 36:26
    warned by the app and got the test and so
    on. So it seems to work from the people I
  • 36:26 - 36:33
    know. Yeah. And I mean, every life that it
    saves counts in the end. So, I mean,
  • 36:33 - 36:40
    nothing is perfect, right?
    H: True very much. Thanks for your answer.
  • 36:40 - 36:45
    But user triplefive would like to know:
    "Why would you think the accelerometer
  • 36:45 - 36:50
    would be a data privacy issue, isn't it up
    to how the sensor data is processed, i.e.
  • 36:50 - 36:54
    stays on the device, is not stored and so
    on and so forth."
  • 36:54 - 36:59
    J: Yeah, of course. But I mean, once you
    give that permission to the app, you need
  • 36:59 - 37:03
    to trust the app, which is first of all a
    binary that you download. I mean, maybe
  • 37:03 - 37:07
    it's open source like our German app, but
    you never know. And then it could process
  • 37:07 - 37:12
    this data. And actually from an
    accelerometer, there have been studies
  • 37:12 - 37:17
    that you not can just, like, do step
    counts, but even stuff like someone turned
  • 37:17 - 37:20
    to the left, to the right, and from this,
    if you have an overlay to a map, you can
  • 37:20 - 37:25
    even reconstruct the path that you moved
    through a city, for example. So that's a
  • 37:25 - 37:33
    big issue, I think.
    H: Alright. Thank you. There's one more
  • 37:33 - 37:39
    question here. Have any of the theoretical
    or possible exploits been tried in
  • 37:39 - 37:42
    practice? To the best of your knowledge,
    that is?
  • 37:42 - 37:48
    J: To my knowledge, not. I mean, I think
    it would only be visible once someone does
  • 37:48 - 37:53
    such an attack, large scale, and then they
    need to manage to have a large deployment
  • 37:53 - 38:03
    of such an attack without being caught.
    So, yeah, nobody did this so far. Yeah.
  • 38:03 - 38:11
    H: OK, makes sense. And there's one person
    who had a comment. They pointed out that
  • 38:11 - 38:15
    there is an open implementation for the
    framework if the user wants to go without
  • 38:15 - 38:20
    Google or Apple at all and still take part
    in exposure notifications. I think it's a
  • 38:20 - 38:24
    fairly recent development.
    J: Yeah, exactly. So I had my slides
  • 38:24 - 38:29
    already finished when that came out. So
    it's on the F-Droid store and it uses, I
  • 38:29 - 38:34
    think, yeah, just like an open source
    implementation so that you can now use it
  • 38:34 - 38:43
    even on your Lineage phone for example.
    H: OK, thank you.
  • 38:43 - 38:48
    J: OK, any further questions?
    H: Yeah, one last question just bumped in
  • 38:48 - 38:54
    here, surfaced over there. Has anyone
    tried to crack the verification server
  • 38:54 - 39:01
    by brute force? The person asking did a
    back on the envelope calculation, back in
  • 39:01 - 39:07
    time. And it seemed possible to just try
    out all possible Tele-TANs at some point.
  • 39:07 - 39:11
    J: All possible Tele-TANs, I mean, so that
    would be like really a brute force that
  • 39:11 - 39:16
    you see in the back-end, right? So that's
    something that you can't just rate limit.
  • 39:16 - 39:19
    And that's probably the only thing that
    you can brute force because all the
  • 39:19 - 39:26
    comparison and so on is done locally on
    the smartphone. So the TANs would be the
  • 39:26 - 39:31
    only weak point in the system. And if
    someone tries to brute force all TANs
  • 39:31 - 39:37
    that, yeah, it's a very obvious attack.
    H: You know, makes sense. All right.
  • 39:37 - 39:40
    Thanks a lot for the talk. Thank you for
    your patience in answering all the
  • 39:40 - 39:46
    questions. I believe that's actually our
    time slot exactly. And with that, I hand
  • 39:46 - 39:52
    over to the news show from Dublin this
    time. Thanks a lot.
  • 39:52 - 39:57
    postroll music
  • 39:57 - 40:32
    Subtitles created by c3subtitles.de
    in the year 2020. Join, and help us!
Title:
#rC3 - Exposure Notification Security
Description:

more » « less
Video Language:
English
Duration:
40:32

English subtitles

Revisions Compare revisions