The rise of IoT (Internet of Things) devices has revolutionized industries and personal lifestyles, making connectivity ubiquitous. However, the rapid proliferation of these devices also introduces significant security challenges, particularly during their decommissioning. Improper handling of IoT devices at the end of their lifecycle can expose sensitive data, create security vulnerabilities, and compromise user trust.

This article examines a specific case: recycling MXChip IoT development boards. During this process, I discovered that even after reflashing the firmware, residual secrets, such as Wi-Fi credentials, remained accessible in the device’s non-volatile memory. I initially intended to donate a board for use in someone’s IoT project but found that the device still retained my Wi-Fi network name and password in memory. Alarmingly, even after reflashing, the board attempted to use these secrets to connect to my home network. This finding highlights the critical importance of implementing robust security hygiene for decommissioning IoT devices. Below, we explore best practices and technical strategies to ensure safe decommissioning.

Understanding the Security Risks

IoT devices often store sensitive information in non-volatile memory, including:

• Wi-Fi credentials
• API keys and access tokens
• Encryption keys
• User data and preferences

These secrets are essential for device functionality but pose significant risks if improperly erased. Attackers gaining access to this data could infiltrate networks, impersonate devices, or retrieve confidential user information. This is particularly concerning in devices like the MXChip, where reflashing firmware does not automatically clear memory secrets.

Key Challenges in IoT Device Decommissioning

1. Persistent Memory Storage: Many IoT devices use flash memory, EEPROM, or similar storage types designed to retain data even during power loss.
2. Insufficient Factory Reset Mechanisms: Built-in reset features may not wipe all sensitive data, leaving critical secrets vulnerable.
3. Complex Data Recovery Risks: Data recovery tools can retrieve deleted information if the memory hasn’t been securely overwritten.

Best Practices for Secure IoT Decommissioning

1. Identify Stored Secrets

Before decommissioning, identify all types of sensitive data stored on the device. For MXChip boards, this includes:

• Network credentials (SSID and passwords)
• Application-specific credentials (e.g., IoT Hub connection strings)
• Device-specific configurations

2. Implement Secure Erasure Techniques

Secure erasure ensures that all sensitive data is unrecoverable:

• Full Memory Overwrite: Use firmware tools or custom scripts to overwrite all memory with random data. For MXChip boards, this involves wiping internal flash memory and other accessible storage.
• Data Scrubbing Algorithms: Employ secure wiping algorithms like those outlined in NIST Special Publication 800-88 (e.g., multiple passes of random or zeroed data).

3. Avoid Relying on Reflashing Alone

While reflashing firmware replaces the application code, it does not guarantee the erasure of secrets stored in separate memory areas. Complement reflashing with explicit memory wipe processes.

4. Validate Device Erasure

After performing the erasure:

• Test for Residual Data: Attempt to read the memory to verify that sensitive data is no longer accessible.
• Perform Forensic Checks: Use data recovery tools to ensure no retrievable data remains.

5. Physical Destruction (When Necessary)

If secure erasure is not feasible, physical destruction may be the best option for highly sensitive devices. For MXChip boards, this might involve drilling through the memory chips or using shredding tools to render the hardware inoperable.

6. Establish Decommissioning Protocols

For organizations managing large fleets of IoT devices, create standardized procedures:

• Document Processes: Outline steps for secure erasure and physical disposal.
• Train Personnel: Ensure technical teams understand decommissioning best practices.
• Use Automation: Implement scripts or management tools to simplify and scale secure wiping processes.

7. Consider Secure Bootloaders

In future development, opt for hardware with secure bootloaders that support authenticated firmware updates and secure data wiping mechanisms.

Case Study: MXChip Decommissioning

During the recycling of MXChip development boards, I discovered that Wi-Fi SSIDs and passwords persisted in non-volatile memory even after reflashing. To address this:

1. Analyzed Memory Architecture: I mapped out memory regions storing secrets.
2. Developed a Wipe Script: Initially, I used old firmware to override secrets with empty strings. While this approach worked to some extent, the proper technique would involve a dedicated script specifically designed to securely wipe out all sensitive data from memory.
3. Validated the Wipe: I used a firmware to validate that no sensitive data remained.

This process underscored the importance of treating decommissioning as a technical, security-critical task rather than an afterthought.

Conclusion

The decommissioning of IoT devices, such as the MXChip development board, requires careful attention to detail and adherence to security best practices. By identifying stored secrets, implementing secure erasure techniques, and validating data removal, individuals and organizations can mitigate the risks associated with device recycling and disposal.

The lessons learned from this case extend beyond MXChip boards to the broader IoT ecosystem. With billions of connected devices in use today, secure decommissioning is not just a best practice – it’s a necessity for safeguarding digital ecosystems.

Test post to see if Jekyll engine is still running. Let’s see if it can genereate test post from github.

Benefits and Key Scenarios of Using Static Websites:

Benefits:

1. Cost-Efficiency: Static websites are extremely cost-effective to host and maintain. They don’t require server-side processing, which reduces hosting expenses.

2. High Performance: Static sites load quickly since there’s no server-side processing. This results in faster page load times and a better user experience.

3. Security: With no server-side components or databases, the attack surface is reduced, making static websites less vulnerable to security threats.

4. Scalability: Static sites can easily handle high traffic loads because content is served from a content delivery network (CDN), distributing it globally.

5. Simplicity: Creating and maintaining static websites is straightforward. There’s no need for complex databases or server setups.

6. Version Control: You can manage static site content with version control systems like Git, enabling easy collaboration and rollbacks.

7. SEO-Friendly: Search engines can crawl static sites efficiently, leading to better search engine optimization (SEO) potential.

Static websites offer a wide range of benefits and are particularly well-suited for scenarios where content is relatively stable and the focus is on fast loading times, simplicity, and cost savings. They’re a versatile solution for various web projects, from personal blogs to documentation portals and marketing pages.

Hosting and deploying a static website in an Azure Storage Account and integrating it with GitHub Actions involves several steps. Below is a step-by-step tutorial to help you achieve this:

Prerequisites:

1. An Azure account. If you don’t have one, you can create a free account at Azure Portal.
2. A GitHub account and a repository containing your static website code.
3. Azure CLI installed on your local machine.
4. GitHub Actions enabled for your GitHub repository.

Step 1: Create an Azure Storage Account

1. Log in to your Azure portal.
2. Click on “Create a resource” and search for “Storage Account.”
3. Click on “Storage account - blob, file, table, queue.”
4. Fill in the required information, including the subscription, resource group, storage account name, and region. Leave the other settings as default.
5. Click “Review + create,” and then click “Create” to create the storage account.

Step 2: Enable Static Website Hosting in Azure Storage

1. After the storage account is created, go to its settings.
2. In the left sidebar, under “Settings,” click on “Static website.”
3. Toggle the “Static website” switch to “Enabled.”
4. Set the “Index document name” (e.g., index.html) and optionally, the “Error document path.”
5. Click “Save.”

Step 3: Configure Azure Storage Account for Static Website Deployment

1. In the storage account settings, go to “Access keys” and note down one of the connection strings (either key1 or key2).

Step 4: Set up GitHub Repository

1. Push your static website code to a GitHub repository if you haven’t already.
2. Create a .github/workflows directory in your repository if it doesn’t exist.
3. Inside the .github/workflows directory, create a YAML file (e.g., deploy.yml) to define your GitHub Actions workflow. Here’s an example workflow file:

name: Deploy to Azure Storage

on:
  push:
    branches:
      - main

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout code
      uses: actions/checkout@v2

    - name: Set up Node.js
      uses: actions/setup-node@v2
      with:
        node-version: '14'

    - name: Install dependencies
      run: npm install

    - name: Build
      run: npm run build # Replace with your build command

    - name: Deploy to Azure Storage
      env:
        AZURE_STORAGE_CONNECTION_STRING: $
      run: |
        az storage blob upload-batch --destination '$web' --source ./build --connection-string $AZURE_STORAGE_CONNECTION_STRING

Step 5: Set GitHub Secrets

1. In your GitHub repository, go to “Settings” > “Secrets.”
2. Click on “New repository secret” and create a secret named AZURE_STORAGE_CONNECTION_STRING. Set its value to the Azure Storage Account connection string you noted down in Step 3.

Step 6: Deploy via GitHub Actions

1. Commit and push the deploy.yml file to your GitHub repository.
2. GitHub Actions will automatically run when you push changes to the main branch, build your website, and deploy it to the Azure Storage Account.

Step 7: Access Your Deployed Website

1. Once the GitHub Actions workflow completes successfully, your static website will be deployed to Azure Storage.
2. You can access it using the Azure Storage Account’s static website endpoint, which you can find in the “Static website” section of the storage account settings.

That’s it! You’ve successfully hosted and deployed your static website in an Azure Storage Account and integrated the deployment process with GitHub Actions. Any future pushes to your main branch will trigger automatic deployments.

In the realm of coding, efficiency and accessibility are paramount. Developers are constantly seeking tools and features that streamline their workflow, enabling them to write better code in less time. One such tool that has garnered significant attention is VSCode.dev, a browser-based version of Visual Studio Code. This online platform empowers developers to seamlessly integrate external libraries into their projects directly from within the browser environment.

What is VSCode.dev?

VSCode.dev is a browser-based version of Visual Studio Code that provides a convenient interface for coding, collaborating, and managing projects entirely online. It offers many of the familiar features and functionalities of the desktop version of VSCode, allowing developers to code from anywhere with an internet connection.

How to Access VSCode.dev

Accessing VSCode.dev is straightforward:

1. Open Your Browser: Launch your preferred web browser on your machine.

2. Navigate to VSCode.dev: Enter “https://vscode.dev/” into the address bar and press Enter.

3. Start Coding: Once the VSCode.dev website loads, you’ll be presented with a familiar coding environment similar to the desktop version of Visual Studio Code.

Using VSCode.dev for Coding

Now that you’re in the VSCode.dev environment, let’s explore how you can leverage its features to enhance your coding experience:

1. Code in the Cloud: Write, edit, and debug your code entirely within the browser environment. VSCode.dev provides a fully functional code editor with syntax highlighting, IntelliSense, and debugging capabilities.

2. Access to Extensions: VSCode.dev comes pre-installed with many popular extensions, allowing you to enhance your coding experience with additional functionalities such as Git integration, language support, and more.

3. Integrate External Libraries: Use VSCode.dev’s built-in features to seamlessly integrate external libraries into your projects. You can search for libraries, view detailed information, and incorporate them into your code directly from within the browser environment.

4. Collaboration Tools: Collaborate with teammates in real-time by sharing your VSCode.dev workspace. You can work together on the same codebase, making it easier to collaborate on projects regardless of physical location.

5. Save and Sync: VSCode.dev automatically saves your work as you code, ensuring that you never lose progress. Additionally, if you sign in with a Microsoft account, you can sync your settings, preferences, and extensions across devices for a consistent coding experience.

6. Accessibility: Since VSCode.dev is browser-based, you can access it from any device with an internet connection, making it convenient for coding on the go or on devices where installing desktop software is not possible.

Conclusion

VSCode.dev is a powerful tool that simplifies the process of coding and collaborating online. By providing a familiar coding environment accessible from any web browser, VSCode.dev enables developers to write code, integrate libraries, and collaborate with teammates seamlessly. Whether you’re working on a personal project, collaborating with a team, or simply coding on the go, leveraging VSCode.dev can significantly enhance your coding experience and productivity.

Github pages are using Jekyll for content generation and i had to install ruby enviroment on my local box to generate content locally and do some testing . I also wants to have ability to deploy it to cloud and preview it when its using fully qualified domain name. So to avoid dev dependencies i choose to have docker image which i can run in any devbox and create simple pipline to deploy blog to azure from my develop github branch before merging changes to master.

You can find docker file in my github with instructions and i am simply including copy o Readme.md from this repo: https://github.com/gtrifonov/docker-jekyll-serve

Running your jekyll site locally and deploying to Azure Container Service

Building and running container locally. Change docker-compose.yml file to insert your git repo url an change container name, branch, ports if needed.

docker-compose up -d --build

Lookup logs locally and at this point you can preview your website locally

docker logs {LOCAL_CONTAINER_NAME} --follow

Assuming you have your azure registry created this command will publish image. You don’t need to rebuild image and publish image with every new blog post (git push)

docker push {YOUR_REGISTRY_FQDN}/jekyll-serve:latest

Create container instance in azure

az container create --resource-group {YOUR_RESOURCE_GROUP} --name {YOUR_CONTAINER_NAME} --image {YOUR_REGISTRY_FQDN}/jekyll-serve --cpu 1 --memory 1 --registry-username {YOUR_USERNAME} --registry-password {YOUR_PASSWORD} --dns-name-label {YOUR_SUBDOMAIN} --ports 80

See a status of your container

` az container logs –resource-group {YOUR_RESOURCE_GROUP} –name {YOUR_CONTAINER_NAME} –follow`

Once testing is done you can delete container to free resources

az container delete --resource-group {YOUR_RESOURCE_GROUP} --name {YOUR_CONTAINER_NAME}

So below is instructions how to run azure cli on raspberry Pi using docker containers.

Prepare your Raspbery PI and run Azure CLI

Install Git and Docker

Git installation command

sudo apt-get install git

Docker installation command

curl -sSL https://get.docker.com | sh

Clone and Build repository

sudo git clone https://github.com/gtrifonov/raspberry-pi-alpine-azure-cli.git

cd .\raspberry-pi-alpine-azure-cli

sudo docker build . -t azure-cli

This will build docker image with title ‘azure-cli’

Running commands in docker image

Starting Docker container in demon mode and giving it name ‘cli’

sudo docker run -d -it --rm --name cli azure-cli

Docker container running as demon with bash shell opened

Verifiying that container running

sudo docker ps

Output

Executing command login to azure

Since docker container is running and waiting any command to be executed you can use docker exec command. Command below will execute azure cli login.

sudo docker exec cli az login

Once you logged in please use Azure Cli command refference to see available commands and there parameters

Hardware

• Raspberry PI 2 Model B
• SD Card 16 GB
• Microsoft LifeCam 6000/ Raspberry PI Camera module
• USB wifi adapter if you don’t have wired Ethernet connection
• Keyboard (optional)
• Mouse(optional)
• Monitor(optional)

You don’t actually need to plugin monitor, keyboard , mouse if you planning to access your PI from your computer via SSH.
You can use either a usb camera or Raspberry PI Camera module. You should get better results with Raspberry PI Camera module since it has a dedicated bus with better throughput compare to usb connection.

Configuring required software

Installing Ubuntu Mate

I decided to install Ubuntu Mate instead of Raspbian based on minimal requirements of Mate in order to have full desktop experience for my kids and potentially wider variety of GUI tools. Ubuntu Mate has image optimized for PI.Since I used Ubuntu once a while,I decide to make it my default OS for Raspberry PI .

Minimum requirements from Ubuntu Mate web site:

• Pentium III 750-megahertz
• 512 megabytes (MB) of RAM
• 8 gigabytes (GB) of available space on the hard disk
• Bootable DVD-ROM drive
• Keyboard and Mouse (or other pointing device)Video adapter and monitor with 1024 x 768 or higher resolution
• Sound card
• Speakers or headphones

Raspberry PI Specs:

• A 900MHz quad-core ARM Cortex-A7 CPU
• 1GB RAM
• 4 USB ports
• 40 GPIO pins
• Full HDMI port
• Ethernet port
• Combined 3.5mm audio jack and composite video
• Camera interface (CSI)
• Display interface (DSI)
• Micro SD card slot
• VideoCore IV 3D graphics core

To write iso image to sd card in Windows simply follow instructions from https://www.raspberrypi.org/documentation/installation/installing-images/windows.md.
Once OS installed you need to configure SSH for remote access, Wifi and make sure that you able to browse internet.

Enabling RaspberryPi camera module in Ubuntu Mate

modifyfile /boot/firmware/config.txt
sudo nano /boot/firmware/config.txt
Just add a line “start_x=1” at the bottom of the file config.txt, save it, and reboot the system.
Try command “sudo raspistill -o test.jpg” to see if it is working

Installing FFMPEG

FFMPEG is powerful tool to work with video and able to encode and push encoded video to live stream channels.
I found and follow instructions from Jeff Thomson blog post which explains how to build ffmpeg for ARM processor and have hardware acceleration turned on.
By defaults you will not have hardware acceleration if you will download precompiled binaries from ffmpeg site. So you need to get source code and compile it for Raspberry PI.
Here is a summary of steps you need to perform:

Install build tools

sudo apt-get install makeinfo texinfo texi2html automake

Compile amd install H264 libraries:

cd /usr/src
git clone git://git.videolan.org/x264
cd x264
./configure --host=arm-unknown-linux-gnueabi --enable-static --disable-opencl
sudo make
sudo make install

Compile amd install FFMPEG:

git clone git://source.ffmpeg.org/ffmpeg.git
cd ffmpeg
sudo ./configure --arch=armel --target-os=linux --enable-gpl --enable-libx264 --enable-nonfree
sudo make
sudo make install

Testing ffmpeg and Camera module:

Once you have all software

Configuring Live channel In Azure Media Services

Now you have to provision Azure media services services and create live channel.

• Go to https://azure.microsoft.com and create account if you don’t have one. There are free trial offers available to play
• Provision Azure Media Services account
  

  Provision Azure Media Services Account

• Create Live Channel
  

  Create Azure Media Services Channel For RaspberryPI

• Specify Channel name and description
  

  Specify Azure Media Services Channel Properties

• Select RTMP ingest protocol
  

• Specify ingest restrictions
  

  Live channel ingest restrictions

  

  Copy Live Stream Ingest Urls

Pushing live stream from Raspberry Pi to Azure Media Services live channel

At this point you have all your hardware,software configured and prepared, live channel is ready to get a live stream from your Raspberry PI device.
It is time to start streaming. I created a simple bash script which using ffmpeg to stream from camera.


nano ~/azure_ffmpeg

#!/bin/bash
modprobe bcm2835-v4l2
INGESTURI=”Paste live channel ingest url here from Azure Media Services”
while :
do
ffmpeg -framerate 30 -r 30 -s 640×480 -i /dev/video0 -vcodec libx264 -preset ultrafast -acodec libfaac -ab 48k -b:v 500k -maxrate 500k -bufsize 500k -r 30 -g 60 -keyint_min 60 -sc_threshold 0 -f flv $INGESTURI
sleep 10
done

chmod u+x ~/azure_ffmpeg
sudo ~/azure_ffmpeg

We created a script ~/azure_ffmpeg. modprobe bcm2835-v4l2 maps PI camera module as /dev/video0 device. if you are using usb camera then you don’t need this line.
Then we are launching ffmpeg and telling it to stream video from /dev/video0 device to our channel with 500k bit rate using ultrafast preset of libx264 codec. We are also instructing to use audio codec since as of now Azure Media Services requires to have both video and audio to be streamed to channel.
Once script is created and saved chmod command is used to grant script execution permissions. Finally sudo ~/azure_ffmpeg launching stream processing.

While script is running you can preview it and publish through portal. Publisher url is url you can share with world to watch your Raspberry PI live stream.

Preview Azure Media Services live stream

What next

In this article i showed you how you can use portal to configure and start live channel. My next steps will be create scripts, so i can manage live channels though raspberry PI itself. So stay tuned.

How to move RaspberryPi to bigger SD card ?

Cloning SD card

1. Shut down Pi ansd remove original  sd card
2. Download and install Win32DiskImager from http://sourceforge.net/projects/win32diskimager/
3. Insert existing original  SD card to card reader
4. Run Win32Disk Manager and specify from which disk to clone and to what image file to save. Click “Read”
   
5. Remove original SD card to card reader
6. Insert new SD card to card reader and click “Write”.Confirm that to you want to continue.
   

Resizing partition

To re-size partitions i followed steps from http://raspberrypi.stackexchange.com/questions/499/how-can-i-resize-my-root-partition.

1. Type sudo fdisk /dev/mmcblk0 and you will see list of partions
2. Delete root partition – type d to delete a partition. Enter partition number 2
3. Create new partition – type n to create a partition. Enter p to define it as primary .Specify partition number: 2
4. You will be prompted to specify start number of partition. select default value which should be equal to value from original list printed in first step
5. Type w to save changes
6. Reboot sudo reboot
7. Resize partition sudo resize2fs /dev/mmcblk0p2

In latest 3.3.0.0 release Azure Media Services team added functionality to support OpenId Connect discovery spec and avoid problem with keys expiration due to rolling logic on identity provider side.
If you are using identity provider which is exposing OpenID connect discovery document (and majority of providers such as Azure Active Directory, Google, Salesforce does), you can instruct Azure Media services obtain signing keys for validation of JWT token from OpenID connect discovery spec.

OpenID Connect Discovery Spec and Json Web Keys (JWK)

OpenID Connect Discovery Spec defines how clients dynamically discover information about OpenID provider. It is JSON document published by provider and contains metadata information about how user system can interact with identity provider.

Here you can find example of discovery doc exposed by Azure Active Directory.

As you can see document has pointer to a resource where you can obtain JSON Web Keys (https://tools.ietf.org/html/draft-ietf-jose-json-web-key-41.).
"jwks_uri":"https://login.windows.net/common/discovery/keys",

A JSON Web Key (JWK) document has collection of signing public keys used by Identity provider which you can use to verify JWT token signature.

Example of Azure Active Directory signing keys in Json Web Keys fromat:
https://login.windows.net/common/.well-known/openid-configuration

Example of Google Json Web Keys.https://accounts.google.com/.well-known/openid-configuration

Using OpenId Connect Discovery Spec together with Azure Media Services JWT token verification

Since Open ID Connect spec has all information regarding signing keys used to sign JWT token you don’t need anymore persist these signing keys in Azure Media Services. All you need to do is instruct Azure Media key delivery service is to use defined openid connect specification during JWT token validation.

Here is a modified code snippet from Azure AD integration example to create Authorization policy and instruct to use OpenId Connect spec for token validation.

You can see example changes in following commit

Based on received feedback example has been updated to use JWT token issued to your web application instead . It is done because you have control to configure that group claims will be present in JWT token. Also you might not have a requirements to talk with Azure Graph API in your app. Azure is planing to remove group claims from JWT token issued for Azure Graph API.

You should not rely on group claims existence in JWT token issued for Azure Graph API if you want to use key delivery token auth based on group claims. You should use JWT token received as part of user authentication process for your app.
Updated OWIN Auth configuration

Also Azure Media Services SDK 3.2.0.0 has been changed to loose contact restriction and allow TokenRestrictionTemplate.Issuer and TokenRestrictionTemplate.Audience to be a string instead of URI type. JWT token obtained from Azure AD during user sign in process has string representation of GUID in Audience claim. In JWT token scenario Media services SDK allows to specify Issuer and Audience as string of any format. For SWT token scenario it should be string representation of absolute Uri.

Please note that  TokenRestrictionTemplate.Issuer and TokenRestrictionTemplate.Audience type changes in 3.2.0.0 SDK is breaking change  and you have to update TokenRestrictionTemplate related code once you upgraded to 3.2.0.0 version.

Also if you implement group based token authentication following my previous version of sample you have to change your code according to updated  https://github.com/AzureMediaServicesSamples/Key-delivery-with-AAD-integration repo in order to have your solution continue to work .