Developments in quantum computing is driving innovation across a range of industries. However, this advancement also has the potential to break the digital security that currently protects us. Post-quantum cryptography (PQC) is an evolving topic that aims to protect against the quantum threat that lies ahead.

The quantum threat

Let's back it up. Most of the security on the internet relies on public key cryptography, most notably, RSA and elliptic curve cryptography (ECC). The magic behind their security is based on the difficulty of solving mathematical problems like factoring large numbers or solving discrete logarithms - problems that are computationally infeasible for classical computers.

Quantum computers leverage quantum bits (qubits) that are more powerful than classical computers at performing certain tasks. It turns out one of their super powers is factorising large numbers and computing discrete logarithms - the very thing keeping us secure today! If you want to read more about this, checkout Shor's algorithm, this algorithm can solve these mathematical problems in moments, whereas classical computers require thousands, if not millions of years to solve.

While quantum computers are still in their infancy and currently lack the power to break asymmetric encryption, researchers predict that within the next 10-20 years, they may reach the capability to do so. This is known as the quantum threat horizon.

Why should we care?

Even though quantum computers are not readily available yet, adversaries are already harvesting encrypted data with the intent to decrypt it in the future. This threat is known as HNDL, "Harvest Now, Decrypt Later". By transitioning to post-quantum cryptography as soon as possible, we can protect sensitive information from being decrypted and exploited in the future.

How to address the threat

In August last year, the NIST (National Institute of Standards and Technology) announced three new post-quantum cryptographic algorithms as Federal Information Processing Standards (FIPS). These algorithms are designed to resist attacks from quantum computers.

• FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM), a module lattice-based KEM originally submitted under the name CRYSTALS-Kyber
• FIPS 204, Module-Lattice-Based Digital Signature Standard (ML-DSA), a module lattice-based digital signature algorithm initially submitted as CRYSTALS-Dilithium
• FIPS 205, Stateless Hash-Based Digital Signature Standard (SLH-DSA), a stateless hash-based signature scheme that began as SPHINCS+

Hands on with post-quantum cryptography

Cloud provider, AWS recently published an article outlining their post-quantum cryptography migration plan which aims to provide a smooth transition for these protections.

If you're looking to test drive PQC now, the Open Quantum Safe project have a GitHub repo for prototyping quantum-resistant cryptography in a range of different applications.

Let's build an nginx web server that negotiates quantum-safe keys so we can checkout PQC in action.

git clone https://github.com/open-quantum-safe/oqs-demos/ .
cd oqs-demos/nginx
docker build -t oqs-nginx .
docker run -p 4433:4433 oqs-nginx

Browsing to the newly created web server, we can see that Chrome throws an error. That's because the quantum-safe cipher suites are not yet included in Chrome's built-in cryptographic library.

Let's build and run curl using OpenSSL v3 and the OQS provider to ensure we can establish a secure connection to the web server using quantum-safe algorithms.

docker build -t oqs-curl .

The docker build should add the OQS provider in the openssl config. Verify the OQS provider is listed by issuing docker run -it openquantumsafe/curl openssl list -providers. The output should resemble the below.

Providers:
  default
    name: OpenSSL Default Provider
    version: 3.4.0
    status: active
  oqsprovider
    name: OpenSSL OQS Provider
    version: 0.8.0
    status: active

Let's test it out by specifying --curves mlkem512

docker run -it openquantumsafe/curl curl -k -vv https://192.168.201.79:4433 --curves mlkem512

Success - albeit a little underwhelming, the output below indicates that the connection between client and server is using quantum-safe algorithms, specifically, mlkem512 as the key exchange mechanism and mldsa65 for the digital signature.

In what's fast becoming a tradition in my household, I'm excited to reveal the latest creation in our custom Christmas display series.

Inspired by the mischievous charm of Dr. Seuss’s Grinch, this year's instalment combines the sweetness of a candy cane with the frosty excitement of a snow blizzard - controlled by the green man himself.

Throw on your Christmas sweater and catch the launch of The Grinch's Candy Cane Blaster below.

The build

I started this project with a few core principles

1. all aspects of the display must be fully autonomous
2. the display must run entirely from mains power
3. the display must have no reliance on network connectivity

We'll achieve these objectives by

1. providing power supplies for the control boards and components
2. inclusion of a meter box to house the electronics
3. using a serial interface instead of wireless to communicate with the control boards
4. incorporating a large bucket to store the snow juice - enough for a week at a time
   

The cannon pump and jet fans are horizontally stacked in PVC piping spanning the length of the candy cane. The snow liquid is pumped from the large bucket into a smaller canister closer to the internal pump. Once activated, the pump propels the liquid, mixes it with air, and delivers it to the front of the cannon, where the jet fans thrust it out.

The cannon moves on a horizontal axis, driven by a high-torque stepper motor connected to a lead screw and mounting assembly.

3D printed parts

A collection of drawings designed and 3D printed for this project.

Snaps

I'm getting married next year, but before I say I do, I need to assemble my groomsmen - cue Anchor Man quotes.

With all the talk of tuxedos, boats and booze, it's starting to feel like a Bond movie. In keeping with this theme, I want to give my groomsmen a one-of-a-kind gift that delivers maximum impact.

While making your own whisky and cufflinks is better left to the experts, I focused my efforts on building the main feature: an interactive touchscreen device that presents the groomsmen with their mission. If this doesn't provide those secret agent feels, nothing else will!

The build

Housing the brains of the touchscreen is a custom 3D-printed plastic enclosure featuring curved edges, a beveled cutaway for the power cable, a small air vent, and recessed screw holes for seamless assembly.

Firmware

The firmware was developed in C for the onboard ESP32 microcontroller, leveraging the Light and Versatile Graphics Library for the user interface.

Mission accomplished

My take on a groomsman gift, fit for a secret agent, complete with the finest whisky, gold cufflinks, touchscreen (with power adapter), encased in a spot UV branded box.

In this blog, we'll capture and analyse the running state of Windows and Linux servers and demonstrate how to extract artefacts from memory to assist with Incident Response investigations.

Windows memory capture

FTK Imager is my go-to tool for capturing memory on Windows hosts. It's lightweight and can run directly from removable media.

The process on Windows is straight forward, go to the File menu, select Capture Memory, review the options and click Capture Memory to begin imaging.

After the capture, generate a hash of the dump to ensure integrity throughout the investigation. If you're new to DFIR, be sure to understand the chain of custody.

certutil -hashfile bb_mem_win.mem SHA256

Linux memory capture

We'll focus on an EC2 instance running Ubuntu. To do this, we'll use LiME, (Linux Memory Extractor), an open-source tool for acquiring volatile memory.

Download the required packages on the target.

sudo apt install make gcc build-essential python3-pip golang git -y

Download and compile LiME.

git clone https://github.com/504ensicsLabs/LiME
cd LiME/src
make

This will produce a file, 'lime-<kernel-version>.ko' in the src directory.

Load the kernel module and specify a path to store the memory dump, for brevity, we'll save it to disk, but you can send this file directly to your destination host.

sudo insmod lime-6.5.0-1017-aws.ko "path=/home/ubuntu/bb_mem.dump format=lime"

To check the module has been loaded, run 'lsmod'.

Generate a hash of the memory dump.

sha256sum /home/ubuntu/bb_mem.dump

Copy the memory dump to your destination host.

scp -i <your-pem> ubuntu@<host>:/home/ubuntu/bb_mem.dump .

Verify the hash on the destination to validate file integrity.

shasum -a 256 bb_mem.dump

Remove the kernel module from the target.

sudo rmmod lime 

Linux memory analysis

After obtaining the capture, we'll use Volatility3 to analyse it on another Ubuntu host. Before diving in, let's review what we need to do:

1. Install debug kernel: This version includes debugging symbols, crucial for memory analysis.
2. Run dwarf2json: This tool converts debugging information from the kernel into a JSON format compatible with Volatility3.
3. Load symbol tables into Volatility3: Provide the JSON symbol tables to enable Volatility3 to interpret kernel structures accurately.

Get started by cloning the Volatility3 repo and installing the dependencies.

git clone https://github.com/volatilityfoundation/volatility3.git
cd volatility3
pip3 install -r requirements.txt

Clone and build dwarf2json.

git clone https://github.com/volatilityfoundation/dwarf2json.git
cd dwarf2json
go build

Add the debug repos and update package lists.

echo "deb http://ddebs.ubuntu.com $(lsb_release -cs) main restricted universe multiverse
deb http://ddebs.ubuntu.com $(lsb_release -cs)-updates main restricted universe multiverse
deb http://ddebs.ubuntu.com $(lsb_release -cs)-proposed main restricted universe multiverse" | \
sudo tee -a /etc/apt/sources.list.d/ddebs.list

sudo apt install ubuntu-dbgsym-keyring
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys F2EDC64DC5AEE1F6B9C621F0C8CAB6595FDFF622

sudo apt update

Install the debug symbols package for our kernel. You can find the kernel version by running 'uname -r' or by using the banners plugin, 'python3 vol.py -f ../bb_mem.dump banners'. In our case, it's 6.5.0-1017-aws.

sudo apt install linux-image-6.5.0-1017-aws-dbgsym -y

Extract debugging information from the kernel image and convert it into a Volatilty3 Intermediate Symbol File (ISF) JSON file.

cd /home/ubuntu/dwarf2json
./dwarf2json linux --elf /usr/lib/debug/boot/vmlinux-6.5.0-1017-aws > linux-image-6.5.0-1017-aws.json

Copy the JSON file to the Volatility3 symbols folder.

cp /home/ubuntu/dwarf2json/linux-image-6.5.0-1017-aws.json /home/ubuntu/volatility3/volatility3/symbols

List the available plugins for Linux.

python3 vol.py --help | grep -i linux. | head -n 5


banners.Banners     Attempts to identify potential linux banners in an
linux.bash.Bash     Recovers bash command history from memory.
linux.capabilities.Capabilities
linux.check_afinfo.Check_afinfo
linux.check_creds.Check_creds
linux.check_idt.Check_idt
linux.check_modules.Check_modules
linux.check_syscall.Check_syscall
linux.elfs.Elfs     Lists all memory mapped ELF files for all processes.
linux.envars.Envars
linux.iomem.IOMem   Generates an output similar to /proc/iomem on a
linux.keyboard_notifiers.Keyboard_notifiers
linux.kmsg.Kmsg     Kernel log buffer reader
linux.library_list.LibraryList
linux.lsmod.Lsmod   Lists loaded kernel modules.
linux.lsof.Lsof     Lists all memory maps for all processes.
linux.malfind.Malfind
linux.mountinfo.MountInfo
linux.proc.Maps     Lists all memory maps for all processes.
linux.psaux.PsAux   Lists processes with their command line arguments
linux.pslist.PsList
linux.psscan.PsScan
linux.pstree.PsTree
linux.sockstat.Sockstat
linux.tty_check.tty_check
linux.vmayarascan.VmaYaraScan

Let's review the capture and find some interesting artefacts.

In this blog, we'll walk through how to reverse engineer and extract sensor data from the Dyson air purifier and send it to my monitoring stack to visualise real-time temperature and air quality.

Getting started

If you've read some of my other blogs, you'll know that MQTT is a commonly used protocol for IoT communications. This device has WiFi connectivity and a mobile-app for controlling its functions, so I expect we'll see MQTT in play here.

To confirm, we'll need to inspect the network traffic from a smart-phone running the Dyson app. Let's start a packet capture on the iPhone.

When opening the Dyson app, we see an MQTT packet with a 'connect command'. That's a good sign, and it's a packet containing the username and password required to subscribe and publish to MQTT topics. Let's make a secure copy of these credentials for use in later steps.

After turning the device on/off and adjusting the fan speed, we start to see the MQTT packets and structure. The topic for issuing commands appears to be '438/YN2-AU-KJA1987A/command', where 'YN2-AU-KJA1987A' is the serial number. Looking at some other packets, we can also determine that real-time data is published to the topic '438/YN2-AU-KJA1987A/status/current' every few seconds when the app is open.

Proof of concept

Now we have the credentials, the topic and the syntax for a few message payloads, let's create a script to request the current metrics from the device.

import paho.mqtt.client as mqtt
from datetime import datetime
import time
import configparser

config = configparser.ConfigParser()
config.read('config.ini')

USERNAME = config['MQTT']['USERNAME']
PASSWORD = config['MQTT']['PASSWORD']

HOST = '<device-IP>'
PORT = 1883
TOPIC = '438/' + USERNAME + '/command'


PAYLOAD_TEMPLATE = '{"mode-reason": "LAPP","time": "%s","msg": "REQUEST-PRODUCT-ENVIRONMENT-CURRENT-SENSOR-DATA"}'

def on_connect(client, userdata, flags, rc):
    if rc == 0:
        print("Connected to MQTT broker")
    else:
        print("Connection failed. Return code =", rc)

def on_publish(client, userdata, mid):
    print("Message Published")

if __name__ == '__main__':
    client = mqtt.Client(protocol=mqtt.MQTTv311)
    client.on_connect = on_connect
    client.on_publish = on_publish

    client.username_pw_set(USERNAME, PASSWORD)
    client.connect(HOST, port=PORT, keepalive=60)

    client.loop_start()  

    while not client.is_connected():
        time.sleep(1)


    current_time = datetime.utcnow().strftime('%Y-%m-%dT%H:%M:%SZ')
    PAYLOAD = PAYLOAD_TEMPLATE % current_time

    print("Publishing message to topic:", TOPIC)
    result = client.publish(TOPIC, PAYLOAD)

    if result.rc == mqtt.MQTT_ERR_SUCCESS:
        print("Message sent successfully")
    else:
        print("Failed to send message. Return code =", result.rc)

    client.loop_stop() 
    client.disconnect()

By creating another small script that subscribes to the topic '438/YN2-AU-KJA1987A/status/current', we can see the request has been successful and we're presented with a JSON array of the current AQ data.

Making the data useful

To use this data, we need to get it into Prometheus. Let's break down what needs to happen:

1. connect to the MQTT broker
2. subscribe to the '438/YN2-AU-KJA1987A/status/current' topic
3. send a request to obtain the current sensor metrics
4. parse the MQTT JSON response and transmit the values to my Prometheus push gateway
5. rinse and repeat every 30 seconds

Here's what that looks like in code...

#!/usr/bin/env python3

import paho.mqtt.client as mqtt
import json
from prometheus_client import CollectorRegistry, Gauge, push_to_gateway
from datetime import datetime
import time
import configparser
import ssl
import socket
import schedule
import syslog

config = configparser.ConfigParser()
config.read('config.ini')

USERNAME = config['MQTT']['USERNAME']
PASSWORD = config['MQTT']['PASSWORD']
MQTT_HOST = '192.168.201.52'
MQTT_PORT = 1883
PUSH_GATEWAY_ADDRESS = 'https://monitoring.brentonbaker.com:9091'
PUSH_GATEWAY_JOB = 'dyson_aq_living_room'

TOPIC_REQUEST = '438/' + USERNAME + '/command'
TOPIC_RESPONSE = '438/' + USERNAME + '/status/current'

PAYLOAD_TEMPLATE = '{"mode-reason": "LAPP","time": "%s","msg": "REQUEST-PRODUCT-ENVIRONMENT-CURRENT-SENSOR-DATA"}'


registry = CollectorRegistry()
temperature_metric = Gauge('dyson_livingroom_environment_temperature', 'Environment Temperature (Celsius)',
                           registry=registry)
humidity_metric = Gauge('dyson_livingroom_environment_humidity', 'Environment Humidity (%)', registry=registry)
pm25_metric = Gauge('dyson_livingroom_environment_pm25', 'Particulate Matter PM2.5', registry=registry)
pm10_metric = Gauge('dyson_livingroom_environment_pm10', 'Particulate Matter PM10', registry=registry)

client = mqtt.Client(protocol=mqtt.MQTTv311)


syslog.openlog(logoption=syslog.LOG_PID, facility=syslog.LOG_LOCAL0)

def log_message(message, level=syslog.LOG_INFO):
    syslog.syslog(level, message)

def on_connect(client, userdata, flags, rc):
    if rc == 0:
        log_message("Connected to MQTT broker")
        client.subscribe(TOPIC_RESPONSE)

def on_message(client, userdata, msg):
    try:
        payload = msg.payload.decode('utf-8')
        process_mqtt_response(payload)
    except Exception as e:
        log_message(f"Error processing MQTT message: {e}", level=syslog.LOG_ERR)

def process_mqtt_response(payload):
    try:
        response_data = json.loads(payload)
        if 'data' in response_data and 'tact' in response_data['data'] and 'hact' in response_data['data'] \
                and 'pm25' in response_data['data'] and 'pm10' in response_data['data']:
            temperature = int(response_data['data']['tact']) / 10.0 - 273  # Formula to convert to Celsius
            humidity = int(response_data['data']['hact'])
            pm25 = int(response_data['data']['pm25'])
            pm10 = int(response_data['data']['pm10'])


            temperature_metric.set(temperature)
            humidity_metric.set(humidity)
            pm25_metric.set(pm25)
            pm10_metric.set(pm10)

 
            log_message(f"Metrics: Temperature={temperature}, Humidity={humidity}, PM2.5={pm25}, PM10={pm10}")

   
            push_to_gateway(PUSH_GATEWAY_ADDRESS, job=PUSH_GATEWAY_JOB, registry=registry)
        else:
            log_message("Received unexpected MQTT message format. Ignoring.", level=syslog.LOG_WARNING)
    except Exception as e:
        log_message(f"Error processing MQTT response: {e}", level=syslog.LOG_ERR)

def job():
    current_time = datetime.utcnow().strftime('%Y-%m-%dT%H:%M:%SZ')
    PAYLOAD = PAYLOAD_TEMPLATE % current_time

    log_message(f"Publishing message to topic: {TOPIC_REQUEST}")
    result = client.publish(TOPIC_REQUEST, PAYLOAD)

    if result.rc == mqtt.MQTT_ERR_SUCCESS:
        log_message("Message sent successfully")
    else:
        log_message(f"Failed to send message. Return code = {result.rc}", level=syslog.LOG_ERR)

if __name__ == '__main__':
    client.on_connect = on_connect
    client.on_message = on_message

    client.username_pw_set(USERNAME, PASSWORD)

    socket.setdefaulttimeout(30)

    try:
        client.connect(MQTT_HOST, port=MQTT_PORT, keepalive=60)
    except socket.timeout:
        log_message("Connection timed out.", level=syslog.LOG_ERR)
        exit(1)

    client.loop_start()

    while not client.is_connected():
        time.sleep(1)

    schedule.every(5).seconds.do(job)

    try:
        while True:
            schedule.run_pending()
            time.sleep(1)
    except KeyboardInterrupt:
        pass
    except Exception as e:
        log_message(f"Unexpected error: {e}", level=syslog.LOG_ERR)
        exit(1)

    client.loop_stop()
    client.disconnect()

Visualising the data

Adding to our existing AQ dashboard, we are now tracking the temperature and humidity from the Dyson.

At this time of year, I hit replay on The National Lampoon's Christmas Vacation and I'm fascinated by the sheer effort one man will invest to ensure Christmas is unforgettable. Well, here's my tribute to you, Clark Griswold. Strap in for the most elaborate Christmas display, perhaps ever!

This is by far the biggest robotic challenge I've undertaken. Last year I made my debut with a rudimentary lolly rocket. It was a hit, but it was missing a storyline and a reason for a lolly rocket to be hanging out in my front garden. This year, I gave myself a little more time to craft a story and build a bunch of high-octane IoT toys and let them rip at Christmas.

Let's set the scene

At the front of the house is an illuminated red button. When pushed, Santa calls out to have a toy car moved from the garage to the sleigh.

A stogie-smoking elf drives out and crashes into a stocking. On impact, lollies are shot from a cannon above and into the hands of some lucky visitors.

Simple right?... well, kinda. Checkout the video below for the end result. If you have an appetite for more, read on...

Self driving car

The hero of the show will be the toy car. I settled on a bright red Audi R8 Spyder.

Off the shelf, these cars are pretty simple, there's a motor connected to a physical switch that changes the polarity, and a switch for the accelerator pedal.

For our display to work, we need complete autonomous driving. To achieve this, all existing electronic parts were stripped and custom components were programmed and fitted. In the true spirit of automation, we also need the car to reset its position and reverse back into the garage. To achieve this, we'll use a 3A DC motor driver to control the polarity.

The software running in the car connects wirelessly to an MQTT broker and waits for the signal. When triggered, the car driving functions activate. To make it more realistic, we'll also add smoke for the car exhaust and turn on the car's lights when driving.

The track

Every race car needs a track. To add some festive cheer, I used WS2812B addressable LEDs to light up the path the car drives on.

Lolly cannon

Learning from last year's build, I came back bigger and better, with a revised version. This model has a linear design and is equipped with pressure piping to launch the lollies higher and faster. To add character, it was embossed with branding, painted, and mounted in a custom hardwood stand.

I promised an auto-refill system this year; a deceptively simple task that was easier said than done, primarily because the lollies are not identical in size, resulting in inconsistent extractions from the hopper. In most cases the lollies would jam and drop different quantities, or none at all.

After making several failed prototypes for extraction mechanisms, I found success building a linear hopper with a stepper motor that moves an internal plate in equal increments to push the lollies vertically into the cannon.

Each time the stepper motor moves, the position is stored on the micro-controller, meaning the device can accomodate nightly shutdowns and remember it's position on initialisation. When the hopper is empty, the software sends the internal plate to the bottom of the hopper and triggers a push notification via the Telegram API to request a refill.

Giant red button

At the front of the house sits a giant red sign with a note to 'press when lit'. When the button is pressed, the magic unfolds.

Soundtrack

The scene is supported by an audio soundtrack. The dialogue between Santa and the elf is split between the left and right channels, making for a more realistic experience.

soundtrack

0:00

/40.803039

1×

Neon sign

To drive home the point of being inside Santa's workshop, I had a workshop neon sign manufactured from Sculpt Neon Signs.

Mobile app

Are IoT toys truely complete without a mobile app? Adding to the laundry list of things to build was a web-based mobile app that can control each element in the display. This came in useful when testing individual components.

Garage

The garage was constructed from pallet wood to house the car and smoke machine.

3D printing

A collection of CAD drawings designed and printed for this project.

Snaps

In response to a need, I developed a light-weight web app that provides on-demand access to call records for users of Microsoft Teams with direct routing. The tool, now affectionally named, callhawk, serves as a suitable alternative to granting people-managers direct access to the Teams admin portal, which can introduce privacy and other security concerns.

callhawk has been packaged for easy deployment with Docker and is available for download on GitHub.

Like most things I work on, I find it useful to know the current state and the expected state. Understanding these states allows you to determine if you're on track, or perhaps, how far off-track you are.

As it relates to technology and especially for IoT devices, the ability to monitor, analyse, and react to changes in a system's state is critical to effective operations.

In this blog I'll touch on a few systems I monitor in the context of my home environment and provide some insights to help get you started monitoring the stuff that you care about.

What I monitor

1. home network
2. Tesla charging
3. air quality
4. brentonbaker.com / cloud infrastructure
5. a few other services (Vault, security systems etc)

The monitoring stack

The stack consists of Prometheus and Grafana. Prometheus is an open-source monitoring and alerting toolkit designed to collect, store, query, and alert on time-series data. Prometheus is part of a broader ecosystem that includes several components that provide comprehensive monitoring and alerting capabilities:

1. Prometheus Server: The heart of the system. The Prometheus server scrapes, stores, and queries time-series data, providing real-time insights.
2. Prometheus Alertmanager: The Alertmanager component handles alerting. It allows you to define and manage alerts based on metric thresholds, predefined conditions, or complex queries. It can group, deduplicate, and route alerts for rapid resolution.
3. Prometheus Push Gateway: Sometimes, systems generate metrics that don't naturally fit the pull-based model used by Prometheus. The Push Gateway is an optional component that enables pushing metrics from short-lived jobs and batch processes, filling the gap in the Prometheus ecosystem. You'll see an example of this with my Tesla & AQ monitoring.
4. PromQL: Prometheus Query Language (PromQL) is a specialised query language for time-series data. It allows you to perform complex queries and mathematical operations on your metrics.
5. Grafana: To visualise and explore metrics, you can pair Prometheus with Grafana. Grafana allows you to create visualisations and dashboards that make it easy to understand your data. You'll see some examples coming up...

Defining the metrics that matter

Now we understand the tools, systems/services we want to monitor. Next is to define the metrics that matter. Be intentional about what you're collecting and how you will use these metrics to inform decisions or trigger actions.

I want to satisfy the following objectives

1. identify when there are sustained periods of high upload and/or download on my home WAN connection
2. monitor resource constraints on my cloud infrastructure
3. determine if my website is down/unavailable for more than 5 minutes
4. track the cost per charge when I charge my Tesla at home
5. track the lifetime cost of Telsa charging at home
6. identify when my Tesla has finished charging at home
7. identify how many new visitors access my website within a 24 hour period
8. be notified when someone accesses the Vault
9. be notified when the Vault disconnects from power
10. monitor the air quality in my home office and graph the last 24 hours

Get building

To achieve objective 1, we can use the Prometheus SNMP Exporter (note: SNMPv3 supports encryption). The SNMP Exporter reads a config file snmp.yml that contains the OIDs to walk.

To achieve objective 2, we can use the Prometheus Node Exporter.

To achieve objective 3 & 9, we can use the Prometheus Blackbox Exporter.

For most other objectives, we need to build our own tooling to extract the metrics and expose them via a HTTP endpoint for Prometheus to scrape. I've provided two different examples below of how to achieve this.

Tesla charging metrics

The Tesla home charger exposes metrics via an API at http://charger-IP/api/1/vitals & http://charger-IP/api/1/lifetime however, Prometheus can't scrape from these endpoints directly. Below is my Python script that queries the Tesla API and pushes the metrics to Prometheus PushGateway every 10 seconds.

#!/usr/bin/env python3

import requests
from prometheus_client import CollectorRegistry, Gauge, push_to_gateway
import ssl
ssl._create_default_https_context = ssl._create_unverified_context


endpoint_url = 'http://<brenton-home-charger-IP>:8018/api/1/vitals'

pushgateway_url = 'https://monitoring.brentonbaker.com:9091'


registry = CollectorRegistry()


response = requests.get(endpoint_url)

if response.status_code == 200:
    # Extract metrics from the JSON response
    data = response.json()
    for key, value in data.items():
        metric_name = key.replace('-', '_') + '_metric'
        metric_description = key.replace('_', ' ').title()

        # Check if the value is numeric
        if isinstance(value, (int, float)):
            metric = Gauge(metric_name, metric_description, registry=registry)
            metric.set(float(value))

   
    push_to_gateway(pushgateway_url, job='brenton_tesla_model3', registry=registry)
    print('Metrics pushed to Prometheus Pushgateway successfully.')
else:
    print('Error:', response.text)

Air Quality metrics

Since my AQ sensor has a PHP library for extracting data from the serial interface, I decided to continue using PHP. The PHP script below updates values of the AQ metrics through POST requests made by another service (extract shown in the second script below) and provides the metrics in a format that Prometheus can scrape.

<?php

// File path to store the values
$dataFile = __DIR__ . '/data.json';

// Load existing values from file if available
if (file_exists($dataFile)) {
    $data = json_decode(file_get_contents($dataFile), true);
    $v1 = $data['v1'];
    $v2 = $data['v2'];
} else {
    $v1 = 0;
    $v2 = 0;
}

if ($_SERVER['REQUEST_METHOD'] === 'POST') {
    // Handle POST request to update v1 and v2 values
    if (isset($_POST['v1']) && isset($_POST['v2'])) {
        $v1 = $_POST['v1'];
        $v2 = $_POST['v2'];

        // Save the updated values to file
        $data = ['v1' => $v1, 'v2' => $v2];
        file_put_contents($dataFile, json_encode($data));
    }
}

// Generate the metrics
$metrics = "# HELP v1_description small air particles\n";
$metrics .= "# TYPE v1_small_particles gauge\n";
$metrics .= "v1_small_particles $v1\n";
$metrics .= "# HELP v2_description large air particles\n";
$metrics .= "# TYPE v2_large_particles gauge\n";
$metrics .= "v2_large_particles $v2\n";


echo $metrics;

function upload($v1, $v2)
	{
		$this->log("sending $v1 and $v2 data");

		$url = 'http://<ip>:8016/metrics'; 
		$data = [
			'v1' => $v1,
			'v2' => $v2
		];
	

		$ch = curl_init($url);
		curl_setopt($ch, CURLOPT_POST, 1);
		curl_setopt($ch, CURLOPT_POSTFIELDS, http_build_query($data));
		curl_exec($ch);
		curl_close($ch);


		$this->listen();
	

	}

Alerting

Prometheus AlertManager can be configured to accomodate alerting based on defined conditions. Below is a rule that sends an email when my Tesla has finished charging.

- name: brenton_tesla_charging
  rules:
  - alert: EVSEStateChanged
    expr: evse_state_metric{job="brenton_tesla_model3"} == 4
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "Charging for Brenton's Tesla is complete"
      description: "Charging for Brenton's Tesla is complete"

receivers:
- name: email
  email_configs:
  - send_resolved: false
    to: <your-email-address>
    from: <your-service-email-address>
    hello: localhost
    smarthost: smtp.sendgrid.net:587
    auth_username: apikey
    auth_password: <secret>
    headers:
      From: <your-service-email-address>
      Subject: '{{ template "email.default.subject" . }}'
      To: <your-email-address>
    html: '{{ template "email.default.html" . }}'
    require_tls: true
templates: []

Display the data

Now the monitoring stack is configured, the data can be queried to build and display real-time dashboards using PromQL in Grafana.

Most vaults require a PIN or a physical key to unlock. Both options are considerably weak for securing anything of value. If you’ve watched the Ocean’s trilogy or Mission Impossible, you’ll know that physical keys can be duplicated, locks can be picked and PINs can be brute-forced.

Let’s build a vault with Multi-Factor Authentication (MFA) and access mechanisms that can’t be forged or cloned.

Unlocking the solution

Having worked in tech most of my life, the solution was abundantly clear. This was a problem well suited for cryptography to solve, and more specifically, digital certificates. Cryptography is one of those things in life that takes a while to master, but once you uncover its power, you want to use it everywhere. This is one of those places.

Over the years, I’ve made a bunch of stuff work with digital certificates, but never anything that controlled things in the physical world. I just had to switch the digital output to a physical output, connect a solenoid to control a locking mechanism and we should have a fairly robust prototype vault.

Wait... what are digital certificates and solenoids?

A digital certificate is an electronic document that contains information about the identity of a person, organisation, or device. It acts as a form of digital identification, just like a passport or driver’s license. Certificates are used to verify the authenticity of digital transactions and to protect sensitive information such as passwords and credit card numbers.

Although certificates (and Public Key Cryptography) provide a secure and centrally managed means of authentication, they are susceptible to attacks on the private keys. If a private key is compromised, an attacker can impersonate the owner of the key, which can result in a security breach, or in our case, unauthorised access to the Vault, and we don’t want that! To mitigate this risk, we’ll use smartcards (I’m a big fan of Yubikeys) in conjunction with certificate authentication.

By combining certificate authentication with smartcards, the private key is protected against theft or duplication. Note: keys must be generated directly on the smartcard to take advantage of this. 

Lastly, a solenoid is an electromechanical device that converts electrical energy into mechanical energy. It consists of a coil of wire that is wound around a ferromagnetic core. When an electric current is passed through the coil, it creates a magnetic field that pulls a plunger inside the solenoid. This will be used as part of our locking mechanism.

Let's get building

For the prototype, I settled on an in-expensive vault from Officeworks. After dismantling the original PIN pad and faceplate, I was left with an empty shell I could use to retrofit my own parts.

The software

The Vault was written in Python and runs as a systemd service. At a high-level, the Vault performs the following functions to make an access determination.

• accept a 6-digit PIN from the keypad (we’ll need this later for cryptographic operations)
• generate a temporary challenge file with 32 bytes of random data
• calculate the hash of the challenge file and temporarily store the result
• extract and temporarily store the certificate from slot 9a (PIV Authentication) on the smartcard
• sign the challenge hash from step 3 using the private key on the smartcard. This is where the PIN from step 1 is passed in to complete the PKCS#15 operation. The resulting signature is temporarily stored

• verify the extracted certificate from step 4 against the root certificate stored on the microprocessor
• extract the public key from the certificate and temporarily store
• Re-calculate the hash of the original challenge file from step 2. Verify the digital signature created in step 6 using the public key.

openssl dgst -sha256 -verify {public_key} -signature {signature} {challenge_file}

• extract the subject distinguished name from the certificate so we know who’s gaining access.
• verify the subject distinguished name and card serial number against a whitelist. If both are valid, activate the solenoid to open the Vault door
• release the solenoid after three seconds to lock the Vault door
• purge all temporary files

What about certificate revocation?

First, let’s define what revocation is. Revocation is the process of invalidating previously issued digital certificates before their scheduled expiration date.

This is useful for situations where certificates become compromised, stolen, or used fraudulently. As I mentioned earlier, the risk of private keys being compromised is mitigated as keys are generated directly on the smartcard. However, we need to account for situations where the physical smartcards may be lost or stolen.

To address these issues, some Certificate Authorities (CAs) revoke the digital certificate and add the certificate to a publicly accessible Certificate Revocation List (CRL) or use the Online Certificate Status Protocol (OCSP) to inform people that the certificate is no longer valid. This would be suitable for devices with internet access, but our Vault still needs to operate without internet or network connectivity. In addition, my private intermediate CA is configured for passive revocation, whereby there is no CRL per se. Instead, certificates are designed to have a much shorter life (usually no more than 24 hours) and are issued more frequently. 

This is not ideal for our use case; I don’t want to be minting new certificates every 24 hours. To solve this problem, I’ve issued longer term certificates and added verification logic to check the card serial number and subject name on the certificate against an array of accepted entities, effectively creating a user/card whitelist. If a card is lost or stolen, the serial number and certificate will be removed from the whitelist.

Bringing it all together

With a donor vault body and working software and hardware, it’s now time to create a plastic faceplate that will house our new PIN pad and NFC smartcard reader.

Using CAD and the power of 3D printing, I created a custom faceplate and mounted it to the Vault.

We’ll also use a handy SendGrid Python library to enable email notifications when the Vault grants or denies access. 

Powering up

Check out the video below to see the Vault in action. 

Security vulnerabilities are inevitable and as time rolls on, we’ve built ways to prioritise and automate remediation. A common approach to resolving security vulnerabilities is to release a new version of an application that addresses the weakness. 

In most cases, software vendors do a reasonable job at making this process as painless as possible. However, I recently stumbled across the need to update the FortiClient VPN and this was far from intuitive. 

It turns out, Fortinet don’t natively support automatic updates of FortiClient unless you pay for their premium product - that’s not great for customers that don’t need any of the extra bells and whistles. 

Below is how I automated the deployment of the updated FortiClient using Microsoft Intune.

Initial setup

Grab the latest installer
Browse to https://www.fortinet.com/support/product-downloads, and download VPN for Windows.

Extract the MSI
Running FortiClientVPNOnlineInstaller from the previous step will present you with a popup showing the download progress. Once the download is finished, the installer will launch. Leave this open in the background.

With the installer open, navigate to: %ProgramData%\Applications\Cache\{look-for-the-latest-UID-here}\<version>

Make a copy of the MSI (FortiClientVPN.msi) as it will be removed when the online installer is closed.

Export working config
On a machine with the VPN already configured, export the configuration to an XML file.

C:\Program Files\Fortinet\FortiClient\FCConfig -m vpn -f staff-vpn.xml -o export -p <enter-password-here>

Create installer
Create a batch file called fortiVPN-install.cmd

@echo off

set PASSWORD=<enter-password-here>
msiexec.exe /i FortiClientVPN.msi /norestart /qn LicenseAccepted_XP=1 FEATURE_SEL_SECFABRIC=0 FEATURE_SEL_SECACCESS=1 FEATURE_SEL_ADVPROTECT=0 FEATURE_SEL_ADDITIONALS=0 FEATURE_SEL_AV=0 FEATURE_SEL_WF=0 FEATURE_SEL_SSO=0 FEATURE_SEL_FW=0 INSTALLLEVEL=3

"C:\Program Files\Fortinet\FortiClient\FCConfig" -m vpn -f staff-vpn.xml -o import -p %PASSWORD%

Bundle the artefacts
Create a new directory and place the following items inside:
– staff-vpn.xml (the VPN config)
– FortiClientVPN.msi (the new VPN client binary)
– fortiVPN-install.cmd (the installer script)

Build and deploy the app

Create a custom intunewin file
Using the Microsoft Win32 Content Prep Tool, build the custom intunewin file. Once finished, the tool will output fortiVPN-install.intunewin

Create a new intune app
Browse to https://endpoint.microsoft.com Click Apps > Windows > Add > select the app type as Windows app (Win32). Select the intunewin file created in the previous step and click OK

Complete the mandatory fields in the Add App options and click Next.

In the Install command, enter fortiVPN-install.cmd 

In the Uninstall command, enter `msiexec /x FortiClientVPN.msi /qn /norestart and click Next.

Complete the two mandatory fields in the Requirements options and click Next.

Select Manually configure detection rules, complete the fields as per below (note, you’ll need to enter the version number you’re deploying in the Value field). Click OK and Next.

Assign the app to a device group and click Next.

Review the options on the Review + create screen and click Create.

It’s the most wonderful time of the year, but it’s also the most competitive time of year with neighbours striving for first place in our neighbourhood Christmas lights competition. 

To keep my winning streak, I need to deliver a display that’s unique, interactive and guaranteed to please. Combining the nostalgic feelings of free-flowing candy at Christmas and my new found rocket obsession, a Christmas rocket that blasts out candy was sure to be the golden ticket I need to take out the win.

So grab your eggnog, slip into something comfy and join me as we build and launch the first ever Baker Christmas Rocket.

The design

With just two weeks until Christmas, we need to design, build, test and deploy the rocket - fast! The rocket is going to form part of my exterior display, so it needs to be durable, water resistant and look the part.

Features

1. illuminated button
2. mission-control touchscreen
3. mobile app
4. automated air refuelling
5. boost

I have zero experience building rockets, but I have built a spud gun or two, and that’s perfect for the job. The spud guns crafted in my younger years were manually operated, meaning you need to manually pump air into the chamber and release a manual trigger to fire. That’s ok for backyard shenanigans, but we need to level up, after all, Christmas is serious business. 

The key to our technical design will be to take all elements that require manual intervention and replace them with automation. We'll swap out the manual air pump for an automatic pump and replace the manual release trigger with an electronic solenoid that will release air from the chamber and shoot out the lollies in the barrel.  We’ll control all these elements with a microprocessor and custom software. We’ll also build a mobile app so the rocket can be launched by a smartphone from anywhere.

Due to time constraints, I can’t build an automatic candy refill system, so we’ll need to recruit an elf to keep our candy chamber filled this year.

The build and installation

The launch

Enjoy the videos below of preflight testing and the main launch event, complete with fireworks!

The La Marzocco GS3 MP is a handmade, dual-boiler coffee machine packed with great features. The most notable is the adjustable paddle on top of the brew head. The paddle controls the flow rate through the coffee grounds during extraction, allowing full control over every shot.

Sophistication aside, this baby isn’t scoring any points for its looks. Luckily, La Marzocco have made these machines with customisation in mind.

The good folks at Specht Design completed a custom re-model for me just in time for Easter. With brass fittings and walnut panels that match my kitchen, it produces espresso just as good as it looks.