TA3M February 2018: Privacy Threat Modeling for The Seattleite

February 19 @ 6:30 pm – 9:00 pm

SURF Incubator
999 3rd Ave Suite 700
Seattle, 98104 United States

6:30 – 7 Casual chat, Cryptoparty / PGP key exchange / Signal
Verification, Intro slide(s)

We’ll have pizza! **

============

Privacy Threat Modeling for The Seattleite

Speaker: Adam Shostack

Seattle Privacy Coalition, led by Adam Shostack and #6 worked through 2017 developing a privacy threat model for an average person in Seattle. If you are an activist, journalist, lawyer, politician etc – these baseline threats still apply. Where and how is privacy violated during the every day activities of someone who lives and/or works in or near Seattle? What can be done to mitigate or protect one’s privacy?

  • Model and categorize the ways data are collected (for example, government vs non-government, is there an opt-out, what does it cost?).
  • Create an inventory of things people do and ways data is gathered to form a set of building blocks, from which to do further analysis.
  • Get to a method, process, or tool that can be applied by different target groups with different threat models effectively and help us think about more holistic defenses.
  • Ultimately, to inform, influence, and identify areas for intervention.

Project homepage: https://seattleprivacy.org/threat-modeling/

Initial post: https://seattleprivacy.org/introducing-threat-modeling-for-seattlites/

Latest update: https://seattleprivacy.org/threat-modeling-the-privacy-of-seattle-residents/

Exciting recent news – Seattle Privacy Coalition was formed around the incident of Seattle Police Department acquiring a drone, and the creation of a DOD subsidized surveillance mesh network. The drone was promptly removed (to LA – sorry LA), but the mesh network remained.. ostensibly unused, until now, finally:

https://www.seattletimes.com/seattle-news/surveillance-system-or-public-safety-tool-seattle-dismantles-controversial-wireless-mesh-network/

Speaker Bio:

Adam is a consultant, entrepreneur, technologist, author and game designer. He’s a member of the BlackHat Review Board, and helped found the CVE and many other things. He’s currently helping a variety of organizations improve their security, and advising and mentoring startups as a Mach37 Star Mentor. While at Microsoft, he drove the Autorun fix into Windows Update, was the lead designer of the SDL Threat Modeling Tool v3 and created the “Elevation of Privilege” game. Adam is the author of Threat Modeling: Designing for Security, and the co-author of The New School of Information Security

=============

Pizza sponsored by Cloudflare.

https://blog.cloudflare.com/cloudflare-wants-to-buy-your-meetup-group-pizza/

Be prepared that there will be an opt-out group photo, taken from the back of the room to fulfill the sponsorship requirements.

Threat Modeling the Privacy of Seattle Residents

[Update Feb 23: Updated spreadsheet based on initial feedback]

[Update, Feb 21: here’s the deck I used: web version, pptx deck.]

I’m pleased to say that we have some first results from our threat modeling for Seattle resident privacy project. In this post, I’m going to share those results, and look forward to what we might do next. (See A Privacy Threat Model for the People of Seattle and Introducing Threat Modeling For Seattlites for more background.)

This blog post provides an overview, and there’s a longer discussion in Seattle Resident Threat Model white paper (draft).

Overall, I’m happy to say that the effort has been a success, and opens up a set of possibilities.

  • Every participant learned about threats they hadn’t previously considered. This is surprising in and of itself: there are few better-educated sets of people than those willing to commit hours of their weekends to threat modeling privacy.
  • We have a new way to contextualize the decisions we might make, evidence that we can generate these in a reasonable amount of time, and an example of that form.
  • We learned about how long it would take (a few hours to generate a good list of threats, a few hours per category to understand defenses and tradeoffs), and how to accelerate that. (We spent a while getting really deep into threat scenarios in a way that didn’t help with the all-up models.)
  • We saw how deeply and complexly mobile phones and apps play into privacy.
  • We got to some surprising results about privacy in your commute.

Methodology

Results

What we can learn from this:

  • Walking and biking are the most privacy preserving commutes. Everything else generates long-term records of your movement. However, some electric bikes have anti-theft GPS built in, as do the new dockless rental bikes.
  • It’s easier to prevent camera tracking on a bike because a helmet is not as attention-grabbing as a mask. Bikes also limit “gait biometrics.”
  • Motorcycles have far less electronics and fewer radios than a car, but still carry license plates and may be tracked via road toll systems. There’s obviously complex tradeoffs involved in motorcycle commuting, but it wasn’t obvious to us going in that privacy could play in those tradeoffs.
  • Between Lyft/Uber and your own car, your own car is trackable in more ways, and more ways that tie to you.  Unless you’re worried about those companies, you’re better off with a taxi or carshare.  If you’re worried about Feds or local government, there are a lot of parties a government will subpoena, and so that’s neutral.  (Taxis vs app-driven: if you call a taxi, your pickup location/phone combo may be recorded.  If you hail it, then pay with a card, your dropoff location may be recorded.  If you hail and pay cash, then you’re more private than with an app.  Thanks to @internmike for teasing that out.)

We also looked at phones. There’s a set of radios, some of which (bluetooh, wifi) can be turned off with less impact on usability. The cellular network radios can only be turned off with a substantial loss of function. We also discussed differences in usability of turning off app access to location between various brands.

Next Steps

One of the things we did not do was a risk assessment for any particular vulnerable group, but we believe that the information we’ve gathered can support and accelerate such analysis. For example, we know that cell site location information can only be disabled by discarding a mobile phone or leaving it in airplane mode. We also know that DHS collected mobile phone information from DACA applicants . We have not attempted to analyze this or its implications, but we’d be happy to do so in partnership with organizations that have specific concerns.

Since we were exploring how we might do this, we have not yet produced a guide to doing it yourselves.

The Raw Data

The raw data is available under a creative-commons attribution license. Here it is as an Excel spreadsheet. (We use xlsx rather than CSV because we needed Excel’s “sheets” feature.) Here’s a version in Excel and a web view, exported HTM here.

CTAB Privacy, January 2018

Hello CTAB Privacy & Cybersecurity! My name is Torgie, and I’m very excited to announce our first meeting of 2018 as chair of this committee! I had hoped to have our first meeting a little sooner, but wanted to ensure everyone had enough time to make it. Please review the details and agenda, and let me know if you want to add or include additional items. Thank you very much!

* * * * *

JANUARY CTAB PRIVACY COMMITTEE MEETING
Date: Tuesday, 1/30/2018
Time: 5pm-6pm
Location:
Seattle Public Library – Montlake branch
2401 24th Ave E, Seattle, WA 98112

Agenda:
– Introductions
– Approve agenda
– Election of vice-chair
– Gather schedules for recurring meetings
– Define 2018 goals
– Open floor / comments

Click and press Send:
List-Unsubscribe: CTAB-PRIVACY-unsubscribe-request@talk2.seattle.gov
List-Subscribe: CTAB-PRIVACY-subscribe-request@talk2.seattle.gov
List-Owner: CTAB-PRIVACY-request@talk2.seattle.gov
Privacy and Mailing List Policy: https://www.seattle.gov/pan/

 

From: Torgie Madison, torgie at gmail dot com

TA3M Seattle for January 2018

In case you’ve forgotten us with our holiday hiatus, we’ll be back in January, so save the date:

6:30 – 7 Casual chat

We’ll have pizza! **

7 – 7:45 Emerald Onion

Emerald Onion has been online for 7 months now! They will provide a review of what they started, current work, and future ideals. More info at https://emeraldonion.org/

7:45 – 8:15 Seattle Privacy Coalition meetup

It has been a while since Seattle Privacy Coalition has had an open members meeting, and a lot has happened! None of these are formal talks, just quick updates on what SPC has been up to, and how you can get / stay involved. More info at https://seattleprivacy.org/

8:15 – 9PM

Currently unknown!

 

** We’re going to try and get food sponsored by Cloudflare this time, if they’ll do it:

https://blog.cloudflare.com/cloudflare-wants-to-buy-your-meetup-group-pizza/

Of course, they require us to list them as a sponsor, but the biggest potential issue is that they require a photo of the group, for proof. The current plan is to have (willing) folks stand in-frame with their backs to the camera, or a mask.

Securing my data for international travel

By Regus Patoff, Anonymous Person

I have a complicated international trip coming up, and I want to protect my private information from border officials. Abroad or in the US, border officials can and do abuse their discretionary power to interrogate travelers, seize electronic devices, demand passwords, and generally inquire into matters unrelated to border safety. This post summarizes my plan. Later I’ll let you know how it went.

 

I’m hard to find online

I started preparing by making my Twitter account anonymous and taking down my personal blog. Now I don’t pop up in Google, so I’m protected from a casual search on my name. It took a full year for my name to fade off of Google, so start this in advance if you want to do it.

I’m not a “target”

I am not important enough to need to worry about state security agencies, and this post isn’t for people who are. . I just want to provide zero information to border guards. All they need to know is that I’m not carrying weapons on a flight, and beyond that, in matters of my heart and mind, they can piss off. My border crossings double as resistance to the erosion of my legal and human rights.

I carry a lot of electronic equipment with me when I travel, though no more that what a typical business traveler might. Basically, a phone, a tablet, and a laptop, though no laptop on this trip . I’m leaving behind many computer services that I need to stay in touch with:

  • A computer server providing websites for myself and others, and also DNS. I need administrative access to that even when traveling.
  • Hidden Tor services that I host.
  • Other various backup services hosted by a major cloud services provider.
  • My personal email hosted by another cloud services provider.
  • A backup email provider, a big one, just in case.
  • My private cloud that I host, full of information that I like to have available all the time and on any device, but which I don’t want to trust to a vendor.

Devices I’m taking along

These are the devices I’ll be carrying:

  • An Android phone (cell and Wi-Fi connectivity, with an add-on SD-card for storage). Serves as a phone, of course, but also as a music player.
  • An Android tablet (Wi-Fi connectivity, with an add-on SD-card for storage). This, with an accessory keyboard and mouse, serves as a full-service computer substitute, an ebook reader, and a mapping+navigation device.

Why Android?

I know that iOS devices are regarded as more secure by the extremely careful and/or extremely threatened. I’m not an Android expert who can improvise my own iOS-equivalent security. However, I am not trying to defend myself against intelligence services at the border, I’m just trying to beat border guards. Stock Android with encryption will work. I prefer Android because I like to tinker, so that’s what I’m taking. Loyal iOS users reading this will have no trouble translating its suggestions into the language of their favorite mobile platform.

I’m also carrying a philosophy

Don’t be a hostage to your stuff. My travel devices are cheap and/or old enough to make losing them to government seizure acceptable. It’s the data that matters.

Sensitive data

My data protection strategy is to keep my sensitive data in the cloud where I can access it when it is safe to do so. My sensitive data in this case includes:

  • Contacts
  • Email
  • Calendar
  • Bookmarks
  • Browser history
  • Passwords
  • Cryptographic keys
  • Photographs

Backups

I’ll be keeping data of this sort in the cloud (private or public) and accessing them through secure connections (HTTPS, SSH) or by secure synchronization services (Android sync, Google Drive, Mozilla sync). I also store configuration profiles for important applications (for example, email) so I don’t have to remember them. I have made several layers of backups for everything, in several locations, including my private cloud and a virtual machine I pay a cloud services provider for. If the sync services fail or I lose my devices, I’ll be able to access my important data from any Internet-connected computer.

Passwords

Passwords are a problem. I use around one hundred strong, random passwords for various websites and services, which means I have to use a password manager to keep track of them. I don’t care much for the hosted password management services, so I run my own and sync its database through my private cloud. My Android devices automatically sync up with my password database.

However, to be truly independent of particular devices and safe from government seizure, I need to carry a few strong but unforgettable passwords in my head. I use one to access my private cloud, where everything important is stored. I have another memorized password for my password database, which is itself encrypted, and one more for my backup email account. In general, the correct-battery-horse-staple (https://xkcd.com/936/) method of password building is the way to go for these master, memorized passwords.

Non-sensitive data

In addition to the sensitive data, I’ll be carrying some relatively bulky, non-sensitive stuff:

  • Music files
  • Map files
  • Ebooks

I’ll keep this data on the external MicroSD cards in each device, unencrypted. I’ll avoid carrying anything controversial. These things are already backed up at home, but are too bulky to sync if I lose them. Worst case scenario, I can’t listen to LCD Soundsystem on the funicular. It’s something of a technical trick, though, to keep sensitive data from being saved to those cards by the ever-helpful Android operating system.

My pilot protocol

Putting all this together, here is my planned device security protocol for before and after entering a country:

  1. Before: Factory reset the devices. Do not begin device setup.[Non-random thought: Will border officials be annoyed to find a factory-reset device? I imagine the Israelis would be annoyed, or the authorities in Urumqi. An alternative would be to set up a false/alternative identity on the device, which would take planning and time. A secondary and very uninteresting Google account would do the trick. However, DO NOT GET CAUGHT LYING TO THE AUTHORITIES. When I was living in {oppressive regime}, I planned my lies very carefully and kept them effectively unfalsifiable.]
  2. After border crossing, set up the devices using Google account credentials.
  3. Choose option to restore from a cloud backup, including apps.
  4. Finish setup, and when prompted, have the device restore all apps.
  5. Retrieve email configuration from the cloud.
  6. Set up SSH keys.
  7. Re-sync browser bookmarks.
  8. Rebuild the home screen, which in my experience is not restored.

Coming soon: How this worked in a “liberal democracy” with draconian security measures, and in an “undemocratic regime” with the same.