Category Archives: Technology

Software Supply Chain Risk Mitigation

1 Reply

Increasingly we are seeing attacks against what is now commonly referred to as the software supply chain.

One of the more notable examples in the last few months was from the Nodejs package management ecosystem [1]. In this case, an attacker convinced the owner of a popular but unmaintained Node package to transfer ownership to them. The attacker than crafted a version of the package that unsuccessfully attacked Copay, a bitcoin wallet platform.

This is just one example of this class of attack, insider attacks of the software supply chain are also becoming more prevalent. When looking at this risk it holistically it is also important to realize that as deployments move to the Cloud the lines between software and services also blur.

Though, not specifically an example of a Cloud deployment issue, in 2015 there was a public story of how some Facebooks employees have the ability to log into users accounts without the target user’s knowledge [2]. This insider risk variant of the supply chain exists in the Cloud in a number of different areas.

Probably the most notable being in the container images provided by their Cloud provider. It is conceivable that a Cloud provider could be compelled by government to build images that would attack a specific or set of customers as part of an investigation, or that an employee would do so under compulsion or in service of personal interests.

This is not a new risk, in fact, management of internal and external dependencies has always been core to building secure systems. What has changed is that in the rush to the Cloud and Open Source users have adopted the tools and resources these cloud providers have built to make this migration easier without fully understanding and managing this risk that they have assumed in doing so.

In response to this reality, Cloud providers are starting to provide tools to help mitigate this risk, some such examples include:

  • Providing audit records of employee access to customer data and services,
  • Building solutions to provide hardware-based trusted execution environments that provide some level of protection from cloud providers.
  • Offering hardware key management solutions provided by third-parties to protect sensitive key material,
  • Cryptographically signing the binaries and images that are published so that their distribution is controlled and tampering post-production can be detected.

Despite these advancements, there is still a long way to go to mitigate these risks in a holistic fashion.

One effort in this area I am actively involved in is in the adoption of the concept of Binary Transparency. This can be thought of as an evolution of legacy code signing models. In these solutions, a publisher places a cryptographic signature using a private key associated with a public certificate of some sort that is either directly trusted based on package origin and signature (such as with GPG signatures) or is authenticated based on the legal identity of the publisher of the package (as is the case with Authenticode).

These solutions, while valuable, help you authenticate a package but they do not provide you the tools to understand the history of that package. As a result, these publishers can produce packages either accidentally or on purpose that are malicious in nature that is signed with their “trusted keys” and it is not detectable until it is too late.

As an example of this risk, you only need to look at RealTek, over the years numerous times their code signing key has been compromised and used to produce malware, some of it targeted such as in the case of Stuxnet [3].

Binary Transparency addresses this risk in a few ways. At its core Binary Transparency can be thought of as an append-only ledger listing of all versions of a given binary, each of these versions having a pointer to a content addressable store where that binary is available.

This design enables the runtime that will execute the binary to do a few things that were not possible, It can, for example, ensure it is running the most recent version of a binary and to only run the binary when it, and some number of previous revisions are publicly discoverable. This also enables the relying parties of the published binaries and images to comp it can inspect all versions and potentially diff those versions to understand the differences.

When this technique is combined with the concept of reproducible builds, as is provided by Go [4] and a community of these append-only logs and auditors of those logs you can get strong assurances that:

  • You are running the same version as everyone else,
  • That the binary you are running is reproducible from the source you can review,
  • The binary are running has not neen modified since it was published,
  • That you, and others, will not run binaries or images that have not been made publicly available for inspection.

A system with these properties disincentivizes the attacker from executing these attacks as it significantly increases the probability of being caught and helps bound the impact of any compromise.

Importantly, by doing these things, it makes it possible to increase the trust in the Cloud offering because it minimizes the amount of trust the user must put into the Cloud provider to remain honest.

A recent project that implements these concepts is the Go Module Transparency project [5] [6].

Over time we will see these same techniques applied to other areas [7] [8] of the software supply chain, and with that trend, users of open source packages, automatic update systems, and the Cloud will be able to have increased peace of mind that their external dependencies are truly delivering on their promises.

  • [1] Node.js Event-Stream Hack Exposes Supply Chain Security Risks
  • [2] Facebook Engineers Can Access Your Account Without A Password
  • [3] STUXNET Malware Targets SCADA Systems
  • [4] REPRODUCING GO BINARIES BYTE-BY-BYTE
  • [5] Proposal: Secure the Public Go Module Ecosystem
  • [6] Transparent Logs for Skeptical Clients
  • [7] Firefox Security/Binary Transparency
  • [8] Contour: A Practical System for Binary Transparency

Secure, Privacy Preserving Key Discovery for End-To-End Encryption

1 Reply

A lot of products today claim to offer End-To-End Encryption but not all of these products offer the same level of protection. Some of the differences between these solutions are rooted in the protocols and cryptography that they use, in some, it is in the way they are implemented and in others it is the way they handle the discovery of the cryptographic keys of the peers involved in the session.

The topic of key discovery itself is a complicated one, on its surface, for a messaging application all you need to do is go to a directory to request the public key pairs associated with the user or their devices you will communicate with. Where things get tricky is how, as a relying party, you can tell if the key discovery mechanism is lying to you or not.

This is important because if the key discovery server is lying to you it can facilitate an impersonation of that user, add a hidden third-party to the encrypted session without your knowledge, or potentially trigger a re-encryption to a device not under your control without your knowledge.

To understand the implications here you just need to look at iMessage. Although many do not know this iMessage is actually End-to-End Encrypted! Matthew Green has done several great write-ups on its protocol [1] [2] and how the lack of verifiability in the key discovery mechanism utilized weakens the overall solution.

The most used End-to-End Encrypted messaging application is probably Facebook’s What’s App. Several years ago a security researcher [3] reached out to The Guardian to discuss what they described as a “backdoor” in What’s App, this “backdoor” was related to how it handled key discovery in device recovery use cases.

As a product person, you often need to make trade-offs to achieve your goals and that was what happened in this case. This “backdoor” was a design decision that was made to ensure billions of users could get some of the End-to-End encryption protections without compromising usability.

A number of security researchers, including myself, spoke up [4] which resulted in the article being updated to correctly reflect this reality [5] flawed reporting about WhatsApp.

Later WhatsApp and how Key Discovery happens came up in the news again, this time in an article from Wired [6. Alex Stamos, the former Chief Security Officer of Facebook, responded to this article [7] affirming some of the article’s points and talking about how a conscious decision was made to enable the associated use case:

“Read the Wired article today about WhatsApp – scary headline! But there is no secret way into WhatsApp groups chats. The article makes a few key points.”

While is response may be true, it is nor verifiably true as it relies on the behavior of the client and not cryptographic verifiability.

This is where systems like CONiKS [8], Keybase [9] and Google’s Key Transparency [10] come into play.

These solutions aim to enable automated trust establishment with untrusted communication through the use of an auditable directory of all of its users’ keys both past and present.

The fact that these solutions provide the auditable history of keys means that both the relying party and subscriber involved in the communication can reliably be made aware of when new keys have been associated with a users account, and importantly what entity added the key to the account.

With this information, they applications the users are using can both prevent messagings (via policy) being sent or notify the user when keys have changed unexpectedly.

This allows messaging clients to verify the identity of users automatically and prevents malicious/compromised servers from hijacking secure communications without getting caught.

On the surface, this sounds much easier than it is to acomplish at least at scale. WhatsApp serves over a billion users, any solution needs to be able to deal with key updates and reads at rates necessary to support such a large user base.

It needs to do this without leaking metadata associated with who the users are communicating with.

And do this without significantly increasing the amount of data a user must download or the time it takes to change keys.

While these are all tractable problems, they are not problems that are solved today in this context.

For this reason, applications that implement End-To-End Encryption typically either provide a mechanism that users who care about these risks can use to out of band verify cryptographic keys in person [11] or simply implicitly trust the key discovery service as an honest actor.

At Google, I have the pleasure of working on Google’s answer to this problem [12]. It is our hope that when complete that applications that need to securely discover keys in a verifiable way can simply download our solution and focus on their application and not need to spend years of energy to solve this problem for their applications.

I firmly believe the best way to ensure the right thing happens is to make sure that the right way is the easy way and fundamentally that is the goal for the Google Key Transparency effort.

  • [1] Attack of the Week: Apple iMessage
  • [2] Let’s talk about iMessage (again)
  • [3] The Guardian is backtracking on a controversial story about WhatsApp
  • [4] Security researchers call for Guardian to retract false WhatsApp “backdoor” story
  • [5] Flawed reporting about WhatsApp
  • [7] Read the Wired article today about WhatsApp – scary headline!
  • [8] CONIKS Project
  • [9] OKCUPID’S FOUNDERS WANT TO BRING ENCRYPTED EMAIL TO THE MASSES
  • [10] Google’s Key Transparency project aims to ease a tough task in cryptography)
  • [11] Safety number updates

Why I chose UniFi vs AmpliFi HD

2 Replies


I just had a brief exchange with a friend on Twitter who suggested that AmpliFi HD, not UniFi was the product Ubiquiti was building for users like me.

I thought folks might be interested in why I didn’t go that route so here is another post 🙂

I did look at AmpliFi HD, in fact, my eldest son tried to convince me to ditch the Google WiFi for AmpliFi HD shortly after it came out.

When I looked into the AmpliFi HD, my conclusion was that it was a less well featured (e.g. it didn’t seem to have the home automation, parental controls, etc features) Google WiFi with better radios and I was largely satisfied with the radio coverage I had with Google WiFi so I was not compelled to make the change.

One of the pain points I did have with my Google WiFi solution was that I had to find places to stash four Google WiFi access points to get sufficient coverage for all the devices in my network. The devices themselves look OK but we really do try to hide all the tech in the house and live by the motto “less is more” so this is a pain we did feel.

The AmpliFi didn’t really have a solution to this problem either, in fact I now probably needed more, smaller units for proper coverage. The upside of which is that those smaller units would have been less visible which would have been nice. On the other hand, I find the kids are often unplugging things in the house to free up outlets or to simply mess with me and the design of the AmpliFi mesh units are such I feared that would happen a lot.

When I looked at the UI on the AmpliFi products my conclusion was it was a stripped down UniFi vs a product designed as a high-end WiFi product. This is in contrast to the Google WiFi which felt like it was a sincere attempt at rethinking the whole user experience.

This combined with the lack of integration with a larger ecosystem (home automation, etc) made it really hard to justify migrating off of Google WiFi.

My conclusion (right or otherwise) from my research was at best I would end up with marginally better coverage and a new set of limitations as a trade-off. It just did not justify the change.

When I re-visited the decision to replace my wireless deployment I was more-or-less fed-up. I did not want to mess with this again anytime soon so I decided to go big or go home. This led me to the switch to UniFi which in turn also led me to the switch to Protect.

If I was the target user the AmpliFi team was looking for I think they missed a few things:

  • I want less clutter, not more, the square design of the AmpliFi presumes public display of a piece of electronics I don’t want that.
  • The mesh does not support wired backhaul, and the distance between where it would be natural to use them would be quite far. Wireless backhaul had caused me some pain with Google WiFi so I was not sure this would work well for me.
  • I also didn’t want 4-6 outlets being occupied in the house, even though the mesh adapters are smaller than the Google Wifi, more is still a pain, especially given kids are not likely to leave them alone.
  • I have some basic home automation and the AmpliFi product doesn’t offer any story here.
  • I liked the parental controls I had with Google WiFi and it seemed I could approximate that but not in an easy way.
  • I liked how I can manage my parents and cousins WiFi’s in Google WiFi; it gives me a one-stop shop for how to deal with issues when people call me. I recall coming to the conclusion this was missing and if nothing else the friction of replacing their WiFi’s to be uniform would have been a barrier.
  • I have Fiber and I understood you had to run the device in bridge mode in this case service which takes away a lot of the features of the AmpliFi HD system.
  • The CloudKey Gen2 Plus having the built-in NVR meant I could consolidate how I dealt with cameras at the same time; one less thing to deal with and after a year the cost savings would allow me to break even and later save.

I basically concluded that my home was “too big” for the AmpliFi HD and that the incremental benefit of switching to it from Google WiFi was not worth the effort.

This could be marketing, this could also be poor product planning, or maybe I was just not the target customer. It is hard to say without knowing a bit more about how the product planning was done here.

In any event as the earlier post states, I’ve gone all UniFi now and I look forward to seeing how that works for us over the next year.

Google Wifi + NEST Cameras vs Ubiquiti for Home Use

3 Replies

I recently made the switch from Google WIFI and NEST Cameras to Ubiquiti Unfi and Protect. A few things motivated these changes and I wanted to talk about them in this blog post.

Background

Google WiFi

The most significant motivator was some network reliability issues that I was experiencing on the Google WiFi. In the end, the problem was not related to the Google WiFi but I could not diagnose without logs which the Google Wifi encrypts. Though I was able to walk through the issue with Google support and ultimately able to localize the issue it took several days of back and forth and required me walking them through exactly what to look for.

The Google Wifi actually performed great overall but we do have an above average number of devices in our house and sometimes we would experience what I believed to be congestion. This is likely because Google Wifi only supports SU-MIMO, the UniFi solution, on the other hand, supports MU‑MIMO. MU-MIMO allows a Wi-Fi router to communicate with multiple devices simultaneously. This decreases the time each device has to wait for a signal and dramatically speeds up the network as a result.

I also experienced some cases where the Google WiFi was falling back to the Mesh wireless solution even though I had a wired backhaul. I never figured out why this was happening but it was not a huge issue.

Finally, we have an outbuilding that is currently using our guest network but since it is on a Guest Network it can not do any IOT style networking where one device talks to another. To address this I needed to either set it up with a physically isolated WiFi of its own or configure a VLAN which I could not do with the Google WiFi.

As a plus, since it is a product designed for home it has features like parental controls which are useful and though it could it could use some work on usability it was actually quite useful.

To be honest, I can not say enough positive things about the Google WiFi, it is a great product that for 99% of people is probably perfect but the sad reality is that we started to outgrow it.

Google NEST Cameras

We had five Google NEST Outdoor Cameras and a Hello doorbell at our house. They worked great and were pretty reliable. We really only had four complaints about these devices.

The first of which is that they did not support POE, this meant when we set them up we had to buy USB to POE adapters and find ways to hide the long and bulky USB power cable they came with.

The second issue is that some of the cameras were on the absolute edge of our wireless network and we would, in rough weather, lose the wireless connection as a result. We did buy another Google WiFi to help with this issue but again it would have been ideal if the cameras were POE based and then this wouldn’t have been an issue.

The third issue is that the move notifications tended to be a bit annoying, we did configure zones help manage this but it was still more obnoxious than I would have liked. To configure zones we had to pay the per camera monthly fee also, this did feel a little bit like extortion — e.g. pay us not to annoy you with notifications.

The fourth and final issue was that the cost and nature of cloud storage. With a total of six cameras, the yearly cost of the NEST solution was significant. It also was dependent on cloud storage which meant my data was being stored exclusively on the cloud. As a Google employee, I have faith in the companies practices relative to managing this data but the recent issues with Ring and Alexa from Amazon poorly managing the data they store relative to their competitive offerings did give me pause.

The reality is that if it were not for the Google WiFi change I discuss above I would have likely kept the NEST Cameras. This is because, despite the above, I was pretty happy with the solution but since I was buying into the Ubiquiti ecosystem it felt like unifying on their solution would not only address the above concerns but overall make things simpler to manage in the long run.

UniFi Wireless

Despite being a very advanced product capability wise it has a pretty easy to use interface for managing. I wouldn’t recommend putting the concepts it exposes in front of the type of users I end up supporting in my personal life but the reality is once it is set up you never really have to deal with that stuff.

Since it is really designed as a business solution and not a home solution it is missing some features that a modern home user might expect. For example, it has no way to share IOT devices as Google WiFi does. It is not integrated with home automation systems either, for example, you can’t use presence and activity of devices to infer if people are home as part of the way you configure your home automation. And it has no “parental controls” concept, though you can manually configure something roughly equivalent.

With that said, since UniFi was designed for businesses, many of its access points are physically attached to the house. This means you need to run wires in walls but it also means you do not have a pile of devices sitting around on horizontal surfaces.

It also does smart channel and power management so you don’t need to worry about such things, so similar to Google WiFi it is largely a set it and forget it solution.

What you end up with when you go with a UniFi based solution is a professional, flexible, moderately easy to use, high-performance solution that is physically installed and as a result non-intrusive to the overall environment.

UniFi Protect

Ubiquiti has two video solutions, Unfi Video that is slowly being replaced and UniFi Protect. I am using the UniFi Protect offering as it is integrated with the CloudKey Gen 2 Plus which I am using to manage my wireless.

The Ubiquiti cameras I chose are the G3, mainly because they were the cheapest of the set and seemed approximately comparable to the NEST Cameras they were replacing. This was important as I intended to sell my NEST cameras to cover the cost of the change.

The G3’s do not have as nice an industrial design as the NEST cameras, they also look more commercial and essentially have no market of third-party accessories (for example skins to obscure the cameras) but they look reasonable enough.

The G3 also does not have a speaker (some other models do, for example, the G3 Micro, though it is an indoor camera) so there is no chance of two-way communication, though they do have a microphone so you can record what’s going on with the video.

I think the biggest gap in the G3 cameras relative to the NEST is they have no zoom, you have to step up to the G3 PRO which is 3x the cost of the G3 to get this.

The upside of this solution over the NEST can be summarized as:

  • No monthly fee per camera,
  • Cheaper cost per camera,
  • Data is stored locally vs on a public cloud.

There are some things that I will miss from the NEST solution, in particular:

  • Using computer vision to analyze the video, for example, do not send notifications when it is a family member, send notifications when a familiar face is seen, or ignore movement unless you see a person (some of these capabilities are only available with the new NEST Cam IQ camera).
  • It is not integrated with home automation systems, Alexa, Google Home or Siri. For example with Google Home, you can ask Google what is happening on a given camera and it will display it on your TV.
  • Having an integrated doorbell solution. I will be keeping NEST Hello, for now, to fill this gap, though having one camera there and the rest in another system is far from ideal.
  • There are no applications to integrate the cameras with AppleTV or ChromeCast so getting the cameras displayed on these devices will involve casting a browser session which lame.

With all that said, the TCO for a multi-camera NEST system is pretty high if you want to retain video and the Ubiquiti solution addresses this effectively.

Wishlist For Ubiquiti

I am installing this system into a home, and that’s not squarely where Ubiquiti is aiming this product at. With that said many new homes get Ubiquiti installs now and if I was in the product team at Ubiquiti I would seriously be looking at what I could do to better serve that market.

Based on my current experience with the product here are some things I think would be nice to have from Ubiquiti.

  • A doorbell camera, it is a shame I need to have to keep the NEST camera to have a complete solution.
  • There should be better camera choices; not having a zoom or speaker in a security camera in 2019 is lame.
  • It is disappointing there is no affordable 4k camera option when consumer products do offer them.
  • I would love to see a less obvious industrial design for the cameras that would work well with skins so you can hide the cameras more easily.
  • Produce a rack kit that allows placing both the security gateway and the CloudKey in a single 1U rack location.
  • I would like to be able to put the Protect server and cameras on one VLAN leaving the network controller on another; they are two different security domains and shouldn’t have to be co-mingled like they are currently [added this to the list after the article was posted].
  • There should be better integration between SDN and Protect, for example, I should not have to set aliases in both manually [added this to the list after the article was posted].
  • If I am going to have to have a Nest Hello and the Protect software it would be ideal if the Nest Hello was integrated into Protect [added this to the list after the article was posted].
  • Integration with Alexa, Siri and Google Home should be in the box.
  • Basic computer vision capabilities in-box, or at least able to opt in to use a cloud CV solution such as Google Vision API or Amazon Rekognition to do intelligent filtering of movement signals in the video.
  • Register the UbiquitiHome.com domain, do dynamic domain registration for subdomains/hosts as part of the on-boarding experience in setup, use Let’s Encrypt to get a certificate for that domain and do away with the self-signed certificate that is currently used.
  • Since the product line is geared towards small businesses and I suspect a good chunk of the home user market is enthusiasts it would be great to have a robust REST API with Webhooks available so custom solutions could easily be added without going into the database to extend capabilities.
  • With a robust set of REST APIs, they could offer a marketplace of applications that users could use to integrate with other systems (IFTT, Google Home, Alexa, etc).
  • Alarm.com integration of NEST Protect would probably be a real winner for the enthusiast community and I would explore a partnership there if I were Ubiquiti.

In Summary

Though I am technically not even done with my Ubiquiti journey it is clear that so far the Ubiquiti networking solution is technically superior but their camera offering still leaves a bit to be desired.

It does seem with the introduction of Ubiquiti Protect which currently has a 20 camera limit, they are looking at how they can better serve users like me. That said, only time will tell how far they go towards providing solutions that are competitive with the consumer-focused offerings.