About xTER SafeContainer
Last updated
Last updated
xTER SafeContainer
xTER SafeContainer is a Linux-driven technology for containerization of a complex pre-configured software, such as media or database server or AI, with strong protection against unauthorized access or any external attack. It has been continuously developed since 2008 by a tiny group of developers, based in Moscow, Russia.
In 2008, PXE boot of pre-configured Linux system with a rendering software was successfully used for diskless workstations stacked in a "renderfarm". Four "slave" nodes booted the same image and then ran the renderer in a cluster controlled from the "master" node.
Ten years later, the same scheme was implemented again, this time to form a cluster of "shards" of a PostgreSQL database. Again, there were "slave" nodes which booted the same image through PXE from the "master" node with tftpboot protocol . This technique required a preparation of a pre-configured customized Linux, considered now as early releases with the current xTER architecture, although not tagged yet. It had been evident to minimize the resource each node had to be running totally in RAM, while only the data shards were kept on disks. Later that year, the boot source was changed to iPXE and HTTPS, aiming at higher security.
Naming
The first variant of the acronym "xETR" was to signify an "elegant technical solution" with the "R" standing for "reshenye" (which means "solution" in Russian), and the first "x" as a tribute to all Un*x-like operating systems. This acronym lasted until mid-2020 and then was changed to the current "xTER" spelling.
In early 2019, an attempt to pack a minimal container with an AI engine inside to live totally in RAM was made. By April, a 1.0.4 xTER version with a TensorFlow object detection module for attached USB webcams was released. The two video streams were analyzed in real time by the AI, and the classified events would find their way into the journal of events, with some events being promptly notified of by SMS or email. In parallel, a simple web-based interface was written in Perl with control panels for video events journal, cameras selection, etc. By July, it became clear that there were already two or three ways for further development. It was decided then to tag them as separate xTER "editions", so first "Home Edition", then later "Office Edition", and later on a minimalist "Router Edition" were added to the scope. While these editions shared the same xTER version (by August 1, v1.12), they were already containers packed to work in specific environment, and supposed to run on bare-metal devices like Intel NUCs with 4-8-16 Gb of RAM, that was enough to hold the running OS and keep some space for temporary files. The "Router Edition" was squeezed to fit into 2GB RAM, as on an outdated notebook, to merely push the filtered content to WiFi clients, setup the filter, keep the logs and display them in admin panel. By November, xTER version 1.16 was released, the first one with an encryption (see Two-level encryption). By the end of the year, 1.17 was released with Qemu support aiming to run Windows inside a running xTER. Safety issues with Windows were covered by two-level encryption, with separate encryption keys held by the xTER and by the client.
Versions 1.18 through 1.22 had been released in all of the Editions, including Home, Office and Router[1]. By November, porting Home Edition to VirtualBox made it possible to run it on Windows hosts, which makes it much easier to run xTER for the first time or as a test.
Kurento Media Server (KMS) has been packed as a separate KMS Edition, and also as a part of Office Edition where it is used for videomail. KMS is a robust media platform with complex setups requiring a thorough expert level configuration [2]. Opposite to that, xTER KMS Edition has a pre-configured Kurento server with simple controls in the admin's interface. The KMS Edition primary target is to deploy nodes of a global network for free audio and video chats (Room-House project). xTER Ecosystem site [3] has been promoted for possible business opportunities. The latest xTER release version as of November is v1.27.
The SafeContainer delivers, unpacks and runs its packed software on a bare metal device or on a virtual machine. This process has three stages: stage A, the required xTER EFI bootloader is downloaded from the xTER github and is used to boot the device/VM the client has full access to; stage B, the OS image and kernel are downloaded from an xTER depot and unpacked in the device's/VM's RAM; stage C, when the OS is up and running, and the designated software starts after the OS, either automatically or manually by the client in the xTER admin's web interface.
To protect the SafeContainer contents against unauthorized access, the two-level encryption scheme has been used. On the first level, the entire file system "A" is created on an partition encrypted with "Cipher A". On the second level, a new partition is created from a file on the file system "A" and is encrypted with a different "Cipher B". The second file system "B" is in this way double-protected against such attacks as cold boot, local entropy variance encryption key search[4] etc., and proved to be unbreakable with standard hacker tools. In addition, as the two levels do not share a common key, this may be useful to guarantee that when two sides have access to the data on the file system "B", neither one can fully own the data. That is, if one of the keys gets compromised or stolen by intruder, the data is not readily accessible because there's the second key which has not been stolen or compromised. And as the file system "A" does not exist on a disk and is held totally in RAM, it is not easy even to get the encrypted data for analysis with standard tools. Ciphers from the AES competition were studied and some of them were tested and selected for use as Ciphers A and B in xTER.[5]
Only "Router Edition" does not require the disk space at all, while other editions do need a lot of disk space, for storage of the database, logs, media files, and so on. The clients are therefore able to attach disks on their device or virtual machine before the boot of xTER, and these may or may not be encrypted later by xTER, depending on the custom clients requests. These disks are recognized and mounted by xTER during the startup.
Though first used solely on bare metal devices, eventually xTER has more often been used as a virtual machine on any host that supports VirtualBox. Requirements exist for minimal RAM, CPU power, and attached storage virtual disk space, which vary with the xTER Editions.[6]
