Wednesday, May 2, 2018

We Edited DNA in our Kitchen. You Can Too!

When our children expressed an interest in DNA and genetic engineering, we wanted to encourage their curiosity and interest. We went looking for books we could read, videos we could watch, etc.

However as we all now live in the future, there is a much more direct way to inspire their interest in genetic engineering: we could engineer some genes, in our kitchen. Of course.

We bought a kit from The Odin, a company which aims to make biological engineering and genetic design accessible and available to everyone. The kit contains all of the supplies and chemicals needed to modify yeast DNA: Genetically Engineer Any Brewing or Baking Yeast to Fluoresce

Altogether the exercise took about a week, most of which was spent allowing the yeast time to grow and multiply. If we had an incubator we could have sped this up, but an incubator is not essential for a successful experiment.

The first step was to create a healthy colony of unmodified yeast. We mixed a yeast growth medium called YPD, rehydrated the dried yeast, and spread everything onto petri dishes. The yellowish gel on the bottom of the dish is the growth medium, the droplets are the rehydrated yeast.

After several days to grow, we could then take up a bit of yeast into a small tube. We would be modifying the DNA of the yeast in the tube, and would later be able to compare it to our unmodified yeast.

The next steps are the amazing stuff.

We used a pipette to add a tiny amount of transformation matrix. This mixture prepares the yeast cells to take in new DNA.

We then used the pipette to add the GFP Expression Plasmid. GFP is Green Fluorescent Protein, and is what makes jellyfish glow in blue light. The GFP Expression Plasmid bundles the DNA segment for the jellyfish gene together with CRISPR as the delivery mechanism.

Swirling the yeast together with the plasmid is how we edited DNA in our kitchen. Over several hours, CRISPR transferred the new gene into the yeast cells in the tube. We incubated the tube for a day, then spread it onto a fresh petri dish to spend a few more days growing.


Voila: shining a blue light on the original dish of unmodified yeast versus the dish with our genetically engineered strain, you can see the difference. Our modified yeast glows a soft green. This is the Green Fluorescent Protein which our modified yeast produces.

This wasn’t a difficult experiment to perform, every step was straightforward and the instructions were quite clear. The kids got a great deal out of it, and are enthused about learning more.

We genetically engineered yeast in our kitchen. You can too!
Genetically Engineer Any Brewing or Baking Yeast to Fluoresce

Monday, April 30, 2018

Automated Blackmail at Scale

I received a blackmail letter in the postal mail yesterday. Yes, really. It begins thusly:

Hello Denton, I’m going to cut to the chase. My name is SwiftBreak~15 and I know about the secret you are keeping from your wife and everyone else. More importantly, I have evidence of what you have been hiding. I won’t go into the specifics here in case your wife intercepts this, but you know what I am talking about.

You don’t know me personally and nobody hired me to look into you. Nor did I go out looking to burn you. It is just your bad luck that I stumbled across your misadventures while working on a job around <redacted name of town>. I then put in more time than I probably should have looking into your life. Frankly, I am ready to forget all about you and let you get on with your life. And I am going to give you two options that will accomplish that very thing. Those two options are to either ignore this letter, or simply pay me $8,600. Let’s examine those two options in more detail.

In email this wouldn't be notable. I probably wouldn't even see it as it would be classified as spam. Via postal mail though, it is unusual. Postal spam is usually less interesting than this.

The letter went on to describe the consequences should I ignore it, how going to the police would be useless because the extortionist was so very good at covering their tracks, and gave a bitcoin address to send the payment to.

There are several clues that this was an automated mass mailing:

  • It helpfully included a How To Bitcoin page, which seemed odd for an individual letter (though crucial to make the scam work).
  • It looked like a form letter, inserting my first name and street name at several points.
  • Perhaps most importantly, I don't have any kind of secret which I could be blackmailed over. I don't live that kind of life. Reading the first paragraph was fairly mystifying as I had no idea what secret they were referring to.

I haven't written about bitcoin before as, other than wishing I'd mined a bunch of coins in 2013 or so, I find it farcical. However cryptocurrency is key in enabling things like this automated blackmail at scale, by providing a mostly anonymous way to transfer money online.

I am by no means the first person to be targeted by this scam:

  • Dave Eargle received an early version of the letter, which called out infidelity specifically. The letter I received was completely vague as to the nature of the scandalous secret.
  • Joshua Bernoff received a letter earlier this month which looks very similar to mine.
  • As the scam has grown, various news outlets have covered it: CNBC, Krebs On Security. The news coverage occurred in a burst in January 2018, covering Dave Eargle.

The amount of money demanded has increased over time. The 2016 letter which Dave Eargle received demanded $2000. The 4/2018 letter which Joshua Bernoff received demanded $8,350. My letter demanded $8,600. I imagine the perpetrator(s) are fine-tuning their demand based on response rates from previous campaigns. More sophisticated demographic targeting is possible I suppose, but the simpler explanation seems more likely.

I'll include the complete text of the letter at the end of this post, to help anyone else targeted by this scam to find it. I'm also trying to figure out if there is somewhere at USPS to send the physical letter to. Using the postal service to deliver extortion letters is a crime, albeit in this case one where it would be difficult to identify the perpetrator.


 
 


 

Hello Denton, I’m going to cut to the chase. My name is SwiftBreak~15 and I know about the secret you are keeping from your wife and everyone else. More importantly, I have evidence of what you have been hiding. I won’t go into the specifics here in case your wife intercepts this, but you know what I am talking about.

You don’t know me personally and nobody hired me to look into you. Nor did I go out looking to burn you. It is just your bad luck that I stumbled across your misadventures while working on a job around <redacted name of town>. I then put in more time than I probably should have looking into your life. Frankly, I am ready to forget all about you and let you get on with your life. And I am going to give you two options that will accomplish that very thing. Those two options are to either ignore this letter, or simply pay me $8,600. Let’s examine those two options in more detail.

Option 1 is to ignore this letter. Let me tell you what will happen if you choose this path. I will take this evidence and send it to your wife. And as insurance against you intercepting it before your wife gets it, I will also send copies to her friends, family, and your neighbors on and around <redacted name of street>. So, Denton, even if you decide to come clean with your wife, it won’t protect her from the humiliation she will feel when her friends and family find out your sordid details from me.

Option 2 is to pay me $8,600. We’ll call this my “confidentiality fee.” Now let me tell you what happens if you choose this path. Your secret remains your secret. You go on with your life as though none of this ever happened. Though you may want to do a better job at keeping your misdeeds secret in the future.

At this point you may be thinking, “I’ll just go to the cops.” Which is why I have taken steps to ensure this letter cannot be traced back to me. So that won’t help, and it won’t stop the evidence from destroying your life. I’m not looking to break your bank. I just want to be compensated for the time I put into investigating you.

Let’s assume you have decided to make all this go away and pay me the confidentiality fee. In keeping with my strategy to not go to jail, we will not meet in person and there will be no physical exchange of cash. You will pay me anonymously using bitcoin. If you want me to keep your secret, then send $8,600 in BITCOIN to the Receiving Bitcoin Address listed below. Payment MUST be received within 10 days of the post marked date on this letter’s envelope. If you are not familiar with bitcoin, attached is a “How-To” guide. You will need the below two pieces of information when referencing the guide.

Required Amount: $8,600
Receiving Bitcoin Address: <redacted>

Tell no one what you will be using the bitcoin for or they may not give it to you. The procedure to obtain bitcoin can take a day or two so do not put it off. Again, payment must be received within 10 days of this letter’s post marked date. If I don’t receive the bitcoin by the deadline, I will go ahead and release the evidence to everyone. If you go that route, then the least you could do is tell your wife so she can come up with an excuse to prepare her friends and family before they find out. The clock is ticking, Denton.

Wednesday, January 24, 2018

I Know What You Are by the Smell of Your Wi-Fi

In July 2017 gave a talk at DEFCON 25 describing a technique to identify the type of Wi-Fi client connecting to an Access Point. It can be quite specific: it can distinguish an iPhone 5 from an iPhone 5s, a Samsung Galaxy S7 from an S8, etc. Classically in security literature this type of mechanism would have been called "fingerprinting," but in modern usage that term has evolved to mean identification of a specific individual user. Because this mechanism identifies the species of the device, not the specific individual, we refer to it as Wi-Fi Taxonomy.

The mechanism works by examining Wi-Fi management frames, called MLME frames. It extracts the options present in the client's packets into a signature string, which is quite distinctive to the combination of the Wi-Fi chipset, device driver, and client OS.

The video of the talk has been posted by DEF CON:

Additionally:

  • The slides are available in PDF format from the DEFCON media server, and the speaker notes on the slides contain the complete talk.
  • The database of signatures to identify devices is available as open source code with an Apache license as a GitHub repository.
  • There is also a paper which describes the mechanism, and which goes a level of detail deeper into how it works. It is available from arXiv.

Tuesday, January 23, 2018

Yakthulhu

Behold: the Yakthulhu. It is a tiny Cthulhu made from the hair of shaved yaks.

(Really, it is. Yak hair yarn is a thing which one can buy. Disappointingly though, they do not shave the yaks. They comb the yaks.)

Saturday, October 21, 2017

On CPE Release Processes

Datacenter software is deployed frequently. Push daily! Push hourly! Push on green whenever the tests pass! This works even at extremely large scale, new versions of facebook.com are deployed multiple times each day (much of the site functionality is packaged in a single deployable unit).

CPE device software tends to not be deployed so often, not even close. There are several reasons for this:

  • Test practices are different.

    Embedded systems is one of the oldest niches in software development and does not have a strong tradition even of unit testing, let alone the level of automated testing which makes concepts like push-on-green possible. One can definitely get good unit test coverage of code which the team developed, but the typical system will include a much larger amount of open source code which rarely has unit tests and is daunting for the team to try to add tests to. Much of the code in the system is only going to be tested at the system level. With effort and effective incentives one can develop a level of automated system test coverage... but it still won’t be close to 95%. System level testing never is, the combinatorial complexity is too high.

    Additionally, with datacenter software, the build system creating the release is often somewhat similar to the production system which will run the release. It may even be the same, if the development team uses prod systems to farm out builds. A reasonable fraction of the system functionality can be run in tests on the builder.

    With CPE devices, the build system is almost always not a CPE being tasked to compile everything. The build system is an x86 server with a cross-compiler. The build system will likely lack much of the hardware which is key to the CPE device functionality, like network interfaces or DRM keystores or video decoders. Large portions of the system may not be testable on the builder.

  • The scale is different.

    Having a million servers in datacenters is a lot, that is one or more very large computing facilities capable of serving hundreds of millions of customers.

    Having a million CPE devices is not a lot. There are typically multiple devices within the home (modem, router, maybe some set top boxes), so that is a couple hundred thousand customers.

    It can simply take longer to push that amount of software to the much larger number of systems whose network connections will generally be slower than those within the datacenter. Multiple days is typical.

  • The impact of a problem in deployment is different.

    If you have a serious latent bug which is noticed at the 3% point of a rollout within a datacenter, that is probably a survivable event. Customers may be impacted and notice, but you can generally quarantine those 3% of servers from further traffic to end the problem. The servers can be rolled back and restored to service later, even if remediation steps are required, without further impacting customers.

    If you have serious latent bug which is noticed at the 3% point of a rollout within a CPE Fleet, you now have a crisis. 3% of the customer base is impacted by a serious bug, and will feel the impact until you finish all of the remediation steps.

    If the remediation steps in 3% of a datacenter rollout require manual intervention, that will be a significant cost. If the remediation steps in 3% of a CPE Fleet deployment require manual intervention, it will have a material impact on the business.

We’ll jump straight to the punchline: How often should one deploy software updates to a CPE fleet?

In my opinion: exactly as often as it takes to not feel terrified at the prospect of the next release, no more and no less often than that.

  • Releasing infrequently allows requirements and new development to build up, making the release heavier and with more opportunities for accidental breakage. It also results in developer displeasure at having to wait so long for their work to make it to customers, and corresponding rush to get not-quite-baked features in to avoid missing the release.
  • Releasing too frequently can leave not enough time to fully test a release. Though frequent releases have the advantage of having a much smaller set of changes in each, there does still need to be a reasonable confidence in testing.

In the last CPE fleet I was involved in, we tried a number of different cadences: every 6 weeks, then weekly, then quarterly. I believe the 6 week cadence worked best. The weekly cadence resulted in a number of bugs being pushed to the fleet and subsequent rollbacks simply due to the lack of time to test. The quarterly cadence led to developers engaging in bad behavior to avoid missing a release train, by submitting their feature even in terrible shape. The release cadence became even slower, and the quality of the product noticeably lower. I think six weeks was a reasonable compromise, and left enough headroom to do minor releases at the halfway point as needed where a very small number of changes which were already tested for the next release could be delivered to customers early.

One other bit of advice: no matter what the release cadence is, once it has been going on long enough, developers will begin griping about it and the leadership may begin to question it (Maxim #4). Leadership interference is what led to the widely varying release processes in the last CPE fleet I was involved in. My only advice there is to manage upwards: announce every release, and copy your management, to keep it fresh in their minds that the process works and delivers updates regularly.