Technological challenges to security of the metaverse
Metaverse implementations will require a huge quantity of data from motion and environmental sensors to track the human participants, and similarly a large number and variety of actuators, transducers and display screens to provide physical (e.g. haptic), audio and visual feedback to users.
Just like other Internet of Things (IoT) devices, every one of these sensor and feedback devices will be connected, almost all wirelessly, to the control systems for the Metaverse, which will almost certainly be based in the cloud.
All of these cloud connections present a huge potential attack surface that a bad actor could use to leverage vulnerabilities and potentially take control of the Metaverse. Would you want to enter a Metaverse that might have been hacked? While it would quite inconvenient if a fleet of smart home light switches were hacked, and got used to initiate a Denial of Service (DoS) attack, or were simply turned on and off when they shouldn’t be, the consequences would be much worse, potentially fatal, if a fleet of Metaverse sensors and actuators were compromised.
Technical challenges to overcome to realise potential of the metaverse
There are many technological challenges that must be overcome before the vision of ubiquitous Metaverses can be realised, as we have seen in the Ready Player One series of books and movies, but the need for absolute security of all the required physical devices probably may not be the top priority of Metaverse developers today. This is a mistake. Users are going to be reluctant to enter a Metaverse if they have concerns about their personal safety. The first inevitable hack of an early, and not fully secured, Metaverse implementation will certainly be widely publicised, fueling such concerns. Unfortunately, security isn’t something that can be bolted on as an afterthought. Security needs to be part of the design specifications for hardware and especially software from day 1. In particular, software needs to be updatable, because the latest software is always going to be the most secure. It is inevitable over time that critical vulnerabilities and exposures (CVEs) will be identified in any software (usually the reason why we have software updates pushed to our phones seemingly every month).
It is essential that these CVEs are fixed as soon as possible before they become exploited by bad actors. Fixing CVEs requires updating the software for the devices, first in the lab, and then deploying the updated software to the device fleets in the field. Most IoT devices are built using some form of open source software, such as Linux. This has many benefits, including the power of the open source community to quickly address bugs and CVEs as they are identified.
The problem for device makers is how to keep track of which versions of each software component is being used in the software distribution for all their different device types. If you don’t have an easy way to check which version you are using, you don’t know if your product is affected by a CVE or not, and you don’t know whether you need to update your device software.
Metaverse security issues can be compounded
This problem is compounded if an OEM has deployed many different types of devices, all developed at slightly different times, each with a slightly different software distribution. Engineers need to comb through the software for each device to figure out if it is affected by the CVE, and if it is, build and test a new software image for every device type to fix the problem. Once the device maker has a tested software image for each of their products, they then need to deploy the update to all their devices which raises many more issues.
Do they have the ability to update their device fleets over their air (OTA), or will they need to send a technician to update each device over the wire - not very practical if you have millions of Metaverse sensors to update! Do they need to update the entire software image on the devices, or can they just incrementally update only the few lines of code that have been changed, which can save huge amounts of costly bandwidth and time? What if the CVE was in the device operating system (OS) or firmware, such as a boot loader? Perhaps the OEM has the ability to update the application software, but a boot loader update may never have been comprehended in the original specifications and may not be possible. And finally, do they have the ability to deploy software updates in waves, perhaps starting with a test update of just a small number of field devices to confirm the software update is issue free, before doing a mass update of every deployed device.
All IoT devices benefit from software development tools that make it easier to manage and update fleets of devices, sometimes for many years, and they need to have the ability to secure that software and communications with devices from the start of the development process.
One company, Foundries.io offers a subscription service, FoundriesFactory, a cloud DevSecOps platform that helps OEM device makers to bring secure IoT and Edge devices to market faster, and manage those devices throughout their service life. Without such a tool, IoT device makers risk finding themselves spending more time maintaining devices they’ve already sold, and not have time to invest in creating new revenue streams from new devices with new features. This problem would be further exacerbated when the devices are part of a Metaverse implementation, where humans are physically interacting with the devices and the consequences of a security breach could be deadly.