Ben Tasker's Blog

Last Nights Storm

We had an awesome double thunderstorm last night, it ran for well over an hour.

I'd been drinking so couldn't drive out to stand and watch from a field, but this post has some gifs of what I did capture

Read more ...

The Curious Case of BitFi and Secret Persistence

For some slightly obscure reasons I've recently found myself looking at the Bitfi hardware wallet and some of the claims the company make, particularly in relation to whether or not it's actually possible to extract secrets from the device.

The way the device is supposed to work is that, in order to (say) sign a transaction, you use an onscreen keyboard to enter a salt, and a >30 char passphrase.

The device then derives a private key from those two inputs, uses it and then flushes the key, salt and passphrase out.

Each time you want to use the device, you need to re-enter salt and passphrase - the idea being that if it never stores any of your secrets, then there's nothing to extract from a seized/stolen device. 

From Bitfi's site we can see this wrapped up in marketing syntax:


The Bitfi does not store your private keys. Ever. Your digital assets are stored on the Blockchains, when you want to make a transaction with your assets (move them, sell them, etc.) you simply enter your 6-character (minimum) SALT and your 30-character (minimum) PASSPHRASE into your Bitfi Legacy device which will then calculate your private key for any given token “on-demand” and then immediately expunge that private key.

For various reasons (see Background) I was somewhat dubious about the veracity of this claim, and ultimately ended up looking over their source code in order to try and verify it.

This post details the results of that examination, the following items should be noted

  • Although not explicitly vulnerabilities, the issues noted below have been submitted in advance to the Bitfi dev team (I did ask previously via email whether email or Bitfi.dev was preferable for raising issues).
  • Incomplete sources are published on Bitfi.dev - example here, so although I include code snippets in this post, it's updated versions of code that's already public - I'm not simply publishing their code on the net :)
  • I probably will make some mistakes: I've been ill, so focusing is hard, and I dislike C# so it's more than possible something's changed without me realising.
  • This is the result of a fairly short code review, and in no circumstances should be viewed or characterised as a full audit
  • In the sources, code version shows as v112

The result is a long analysis, so some may prefer to jump to the Conclusion.  

Read more ...

The Importance of Provider Redundancy

Icon made by Smashicons from flaticon

Back in the days before cloud computing, it used to be accepted (if somewhat resented) by management types that having redundant systems in place was important if you cared - even a little - about uptime.

In today's industry, those same management types generally understand that it's still important to have multi-region availability, with instances running in completely distinct provider regions, so that an outage in one area doesn't impact your ability to do business.

What doesn't seem to be quite so widely understood, or accepted, though is the importance of ensuring that systems have redundancy across providers. It's not just management types who are making this mistake either, we've all encountered techies who are seemingly blind to the risk and view it as an un-necessary additional cost/hassle.

Rather than typing "the provider" throughout this post, I'm going to pick on AWS, but the argument applies to all Cloud providers.

Read more ...

Configuring Pi-Hole to update blocklists more regularly

By default Pi-Hole updates it's block lists once a week.

Broadly speaking, this is fine for blocking Ad domains (although the recent trend towards advertisers generating new domains does undermine that a bit).

But, if you've added a Phishing block list (as detailed in Building Your Own DNS over HTTPS Server), this is far less optimal - Phishing domains tend to do the majority of their damage during the first 24 hours, so only getting an update into the blocklist (potentially) 7 days later isn't much use.

In this post we'll walk through the (simple) procedure to have Pi-Hole update the gravity lists more frequently

Read more ...

An argument in favour of application level name resolution

Recently I published some documentation detailing how to build and run your own DNS-over-HTTPS (DoH) server.

As I mentioned at the beginning of that documentation, there's been a certain amount of controversy about DoH vs DNS over TLS (DoT).

One thread of that argument is along the lines that name resolution should be handled at the OS level (so that all applications get the same result for a given name - improving troubleshooting - as well as giving some caching benefit, versus applications resolving names themselves).

Generally I've found that argument fairly persuasive, but also taken the view that DoH being implemented at the application level is the result of a general lack of availability/uptake of DoT at the OS level.

In other words, whilst it's not ideal for applications to be resolving names themselves, it makes an (arguable flawed) privacy-enhancing solution available now, rather than continuing to wait for an (arguably) better solution to actually get adopted (and ignoring whatever reasons led to that lack of adoption).

But, I've begun to change my mind on whether applications doing resolution themselves really is a problem, or whether it's actually more beneficial when considered alongside some of the aims of DoH

Read more ...