A custom BIOS/UEFIfirmware that has higher security to a hardware vendor's BIOS/UEFI, can be installed. It sounds like a good idea to do this. The Qubes OS 4.0.3 guidance in fact recommends installing, in place of a hardware vendor's BIOS, the custom BIOS/UEFI called Coreboot.
"All ChromeOS devices (Chromebooks, Chromeboxes, Chromebit, etc) released from 2012 onward use coreboot for their main system firmware. ..." - https://doc.coreboot.org/distributions.html
The above excerpt indicates that flashingChromebooks with a Coreboot firmware freshly downloaded through a hopefully non-compromised device, likely works. Using the MrChromebox Coreboot firmware for a Chromebook seems likely to be more secure than the standard Chromebook firmware.
The Heads BIOS/UEFI boot firmware system keeps a bootloader stored in ROM, so that the bootloader no longer has to be an attack vector in relation to storing a bootloader on a drive (HDD, SSD, etc.) Heads appears either to be an adaptation of Coreboot, or a system that runs over Coreboot. Either way, using Heads instead of vanilla-flavoured Coreboot appears to provide better security.
Heads (and perhaps also Coreboot), can make use of a motherboard's TPM (Trusted Platform Module), to ensure computer firmware has not undergone any tampering[1]. It can also be used to ensure a high-quality password security system, partly because of the destroy-key-when-attacked security but also because of the system being present in the TPM.
The National Cyber Security Centre for the UK (NCSC) highlights the importance of updating firmware, and provides related guidance and information (see here and here).
Installed operating systems (OSes) must be safeguarded—they are vital for ensuring computer security.
Using an OEM preinstalled OS is prone to the MITM attack of having the related machine intercepted and hacked before reaching the customer (especially on a targeted-individual basis). More secure ways for obtaining an OS’s installation software are described in this document, in the section entitled “Regarding how to obtain software”.
Once installed, the security provided by the OS, will likely mean that one can then download further software from over the internet without much worry (assuming reasonable security precautions are taken).
Some general security advice in relation to using an operating system, is for users to have
an administrator account that is different to the standard account users use for everyday computing. The standard account has fewer privileges. The more powerful administrator account, that also has higher associated security risks, should also have a “minimised” exposure to risk due to it being used only when needed—when not needed, the less risky standard account is instead used.
It can be slightly irritating to have to choose Linux over Windows, given the various advantages in using Windows, but can be necessary to ensure security. Windows emulators such as Wine, can perhaps be effectively always used whenever needing to run some software meant to be run over Windows. There is unlikely much point in dual-booting between Windows and Linux because if Windows is hacked, then the Linux installation can then also be hacked through the hacked Windows, thereby undermining the security advantages Linux affords; in fact this point is specifically mentioned in guidance on the Qubes website.
If going for Linux, the Qubes 4.0.3 distribution of Linux appears to be perhaps the best in terms of being most secure, and is at least one of the most secure distributions of Linux. So installing Qubes OS 4.0.3, if installing a Linux distribution, seems like a good idea.
Some platform-specific (and OS) guidance from the National Cyber Security Centre (NCSC) is available here.
Qubes OS 4.0.3 side-by-side with other operating systemsedit
Qubes OS 4.0.3 is documented as not coping well with software that specifically benefits from 3D-optimised hardware. Since a user may well want to use such optimisation, the best way to use such optimisation on the same machine might be to do something like, or the same as, the following:
Install a Linuxoperating system, with good security but still with the capacity for being able to utilise 3D-optimised hardware, on an SSD external drive, such that this other operating system is not run over Qubes, but instead run separate to Qubes.
When wanting to use this other Linux OS, disable the internal drive (containing Qubes) in either:
After using the non-Qubes installation, because of the possibility of malware being introduced into the BIOS firmware by the non-Qubes installation, optionally flash the BIOS's firmware to ensure better that the Qubes installation isn’t compromised through firmware malware when you next use Qubes.
By following the above steps, and choosing the most secure options in the steps, because of:
the disabling of the internal drive via the BIOS,
the physical disconnection of the drive containing the Qubes installation, and
the flashing of the BIOS firmware before the ‘reconnection’ of the
Qubes installation,
any such other OS should not be able to access or even ‘touch’ the Qubes OS installation, thereby hopefully safeguarding the Qubes installation from attacks conducted through the other presumably-less-secure OS.
How to ensure installed operating system is not compromised via an evil maid attack, during periods when machine is not meant to be onedit
the system is re-encrypted with a brand new key every so often
(to mitigate against the exploitation of newly discovered security vulnerabilities that are in historic copies of the encrypted system[3]),
then it appears that this will quite likely adequately secure the operating system from becoming compromised via an evil maid attack, during those periods in which legitimate users have set the machine to be in a powered-off state.
An alternative way is to keep the operating system stored on a read-onlylive DVD[4] that you lock away, and of which you perhaps keep multiple copies stored in different locations in order to help make sure any one selected copy is the “genuine article”[5]; however, be aware that system speed is often degraded when running the operating system in such fashion.
Secret criminal societies will likely find it much harder to replace every single copy of a particular software with malware-modified versions, in a large physical shop, than to do the same replacement with downloads or goods delivered to specific end-users. Because of this, the broad security principle outlined in the “User randomly selecting unit from off physical shelves” subsection probably applies at least to the obtaining of the foundation software required for operating a computer (i.e. the operating system, BIOSfirmware, etc.) and at least in terms of part of the overall solution used.
Borrowing library software DVDs and CDs may be another channel through which software can be usefully obtained.
Once an operating system and BIOS firmware have been (re-)installed for a computing device, downloading software through the device with standard security precautions in place (eg. using HTTPS connections, verifying signatures, etc.) may become sufficiently secure for obtaining further software.
What are you to do if all your computing devices have been compromised, and security cannot be reestablished in the devices except through using certain software on the devices that is available only via internetdownloading (such as certain firmwarere-installers)? It can be expensive to buy a brand new computer, if not on one particular occasion, then on some number of occasions whenever security needs to be re-established.
Getting an uncompromised smartphone and obtaining software with itedit
The advent of smartphones appears to be of great benefit to this problem. It looks like a cheap uncompromised smartphone for simply downloadingfiles over WiFi, that is shrink-wrapped and boxed fresh from its factory, can easily be bought by first physically visiting a large store geographically distant from an end user's address, and then secondly by randomly and personally selecting such a phone from very many other such phones, off the physical shelves of the visited store (principle outlined in “User randomly selecting unit from off physical shelves” section).
The price of purchasing such a phone might initially be of concern, with minimum prices for such a phone perhaps starting at around the £40 mark. However, it should be possible to recoup some of the money spent, by simply selling the phone on as a second-hand device once it has been used. There is a possibility that a tablet might be cheaper than a phone; prices should be investigated regarding this.
It is also generally better to use a brand new phone, rather than an old phone even if you are sure the old phone hasn't undergone any tampering. The reason being, is that brand new phones should be more secure, due to:
Using a smartphone or tablet, perhaps is more secure than using a computer keyboard, because a screen-based and software-based key scrambler perhaps effectively reduces or removes the effectiveness of key loggers. Also, smartphones are very popular, this should make random selection by physically going to a store[6], much easier and more potent (because so many units should be available 'on the shelves' and because more stores should stock them.) Also, reliance can be made on a higher amount of security testing because of the greater market need for secure mobile phones, and because of the greater unit production, compared with devices like the Raspberry Pi device.
especially when you suspect your existing computers may have been compromised, was to buy a brand new Raspberry Pi Zero product, from off the physical shelves of a store, by means of users personally selecting a device at the store using random selection[7], and then to use that device for downloading.
Because of the device's prevalence and unit price, it probably can be easily bought by physically visiting a store and then personally selecting a unit by random selection from off the physical shelves[8]—this protocol is a good way to ensure better that no tampering or fraudulent replacement has been performed on the unit.
The OS integrity can perhaps be further trusted by first copying the OS off onto an SD card or USB memory stick, and then by using another computer, sometimes even if the other computer has been potentially compromised, to check whether the OS matches a copy of the OS downloaded through the other computer.
The operating system is updated in a timely manner for better security.
Raspberry Pi has been around a while, so is likely more trustworthy and secure because of that.
It appears to have a wide audience, including individuals in the security community, and so likely has improved security and reliability because of that.
According to Micah Lee in the Qubes OS video hosted here(go to 29m:47s), using USB instead of PS/2 for plugging in your keyboard, is something of a security risk.
a hacker can take control of the TV output to display a completely different output in order to phish for your security credentials.
Whilst it is true that related hardware can be bought in such fashion that the I/O-device vulnerabilities are not so important, doing so whacks up the overall cost of the set-up in such fashion that alternatives become more appealing.
In spite of the cons outlined above, a primary advantage of a Raspberry Pi or similar solution, remains—namely, that of it moving along the lines of being fairly bare-bones. With some tweaking, the Raspberry PI or a similar device, can be made part of an effective security solution to the problem outlined in this writing, and perhaps could even be a marketable product. However, until such a product exists, because of the cons, it is advised that one use a smartphone (as described in the previous section) rather than a Raspberry Pi Zero device. It's a shame because with some fairly straight-forward modification, perhaps the Raspberry Pi Zero device would be ideal as the main device used to solve the security problem addressed here.
According to Andrew "bunnie" Huang, because of the presence of reprogrammablefirmware “strapped” to a reasonably powerful microcontroller, combined with a high amount of flash memory, with all of these things embedded in single SD cards costing very little, SD cards could be a very cheap source of hardware for DIY projects. Additionally, SD cards carrying WiFihardware also exist. Therefore, reprogramming a WiFi enabled SD card as a “secure downloader” (as just suggested for some adaptation of the Raspberry Pi Zero device) may well be possible. If possible, it may be cheaper than trying to do something similar with a “Raspberry Pi” kind of device, as well as more secure because it has so many fewer “bells and whistles”, and because SD cards are much smaller meaning that it is more difficult to tamper physically with SD cards. However, it should be borne in mind that reprogramming it appears only to be able to take the form of a hacking kind of project because the specifications for interfacing with such embedded microcontrollers appear to be entirely unavailable outside of the production processes used for SD cards.
Should Qubes OS (and other software) be built from scratch? Reason would seem to suggest that detecting malware in software is easier if you have the software's source code to check. The reasons for this are as follows:
certain malware patterns are quite likely more discernible upon examination of the source code rather than the compiled code,
🄰🄽🄳
discrepancies between freshly compiled source code, and historically compiled source code, can uncover malware introductions that occur post compilation.
GitHub's security information published here seems to support point 2. Reflection on how programming mostly involves the application of design patterns(such as the implementation of certain algorithms, data structures, etc.) also clearly inclines one to believe that malware can be detected in source code on occasions where detection in compiled code is either difficult or impossible. Also, publicly hosted source code (such as in public GitHub repositories), can have “many eyes on it” through public peer review of the code, including those of security researchers, checking over the code (sometimes simply as a step to accomplishing something completely different, such as the contributing of new code to a repository) so as to reveal malware. GitHub also appears to have special provisions for detecting malware, as documented at the GitHub internet address just mentioned. If the detection of malware in source code is computationally expensive, perhaps providers like GitHub, can (or maybe they already do) run automated AI malware-detection algorithms in the background on their repositories using powerful servers, perhaps sometimes running for several months, for the detection of malware in source code. Also, GitHub’s collaborative development structure essentially audits all source code changes, which undermines many of the efforts aimed at trying to introduce malware into software. These thoughts incline one towards choosing to obtain source code from GitHub rather than the website of some specific software development entity. They also incline one towards choosing to build from source.
It’s not clear that reproducible builds offer a significant security benefit over simply compiling from source. However, they probably do given the promotion of it by other notable individuals. It seems like reproducible builds are good at uncovering certain security compromises more in relation to compromises in the Provider's system than compromises in the user's system. However, since the two (the Provider's system and the user's system) are interdependent, the uncovering of such compromises necessarily means that the user's security is also somewhat increased.
Full system encryption, full disk encryption (FDE)edit
Full-system encryption should probably be considered as required when using a computer for business purposes.
There are various pieces of software that can provide such encryption. Usefully, the Qubes OS FAQ says that Qubes OS 4.0.3 has full-disk encryption installed by default, so if you use Qubes 4.0.3, you probably won't need to take extra steps to make sure full-disk encryption is set-up.
Malicious sneaky replacement of FDE system with historic clone of system that has known vulnerabilitiesedit
An attacker can exploit that a particular system has been full-disk encrypted with the same key used over a long period of time. For example, suppose Windows was full-disk encrypted with the same key three years' ago, and that an attacker cloned the system three years' ago. Then suppose that in the present day it was known that there were security vulnerabilities with that historic cloned Windows installation. An attacker could maliciously replace the contents of the system disk with those recorded three years ago, unbeknownst to the user. The user logs in, with their same password, and doesn't suspect that the system is three years old. Then the attacker can potentially exploit security vulnerabilities in the system that is used by the user in the present day, even though the system is in fact the user's system from three years ago, with security holes in it that are known about in the present day.
Way to mitigate against this type of attack: change full-disk encryption keys and passwords on a regular basis, quite frequently (perhaps once per month) but not too frequently so as to wear out the system disk unduly (usually a HDD or SSD). Interestingly, could this solution benefit from old hard disk drives that users give away for free, so as to mitigate against the costs of having to deal with the deterioration of drives due to them being frequently re-encrypted each time the key changes
Could it be a good idea to perform factory resets on computing devices, on a regular basis? If doing such resets gets rid of any malware that may have managed to get its way on to the devices, perhaps it is a good idea to do such resets perhaps once per week, on a Monday, just before starting the working week.
Doing a factory reset for a conventional laptop is more of an issue. Intensive use of the internal drive, for any frequent periodic factory resetting, is likely going to shorten the lifespan of the internal drive, significantly, detrimentally, and unacceptably, in the situation where replacing the drive is not an option (perhaps because of financial constraints). Also, the amount of data requiring backup between such resets, is likely going to be inhibitive. Please note that if you decide to use a live DVD/CD for the loading of your operating system and perhaps also for other pieces of software, where the DVD/CD has been contrived so that it is virtually impossible to change the data on the medium (see the section entitled “Rewritable media vs optical ROM discs” to find out how to do this), factory resetting with respect to your operating system and perhaps other software, can become entirely unnecessary, and in certain situations, can overcome these issues regarding the undue deterioration of internal drives.
Internetbandwidth and quota will be needed to cope each time a device needs to be updated after such factory resetting. A standard WiFi router should normally be able to be used without security concerns for such updates because man-in-the-middle (MITM) attacks normally are not possible due to HTTPS connections (or other such connections) being used for the updating. However, a vulnerability does exist if any of the historic security certificates upon which reliance is made, and that date back to the time of the production of the device, become compromised (which can happen outside of your systems) in the intervening time between the time of the device’s production and the time when the factory resetting is performed. If this vulnerability is considered a significant danger, an owner may deliberately choose not to factory reset their device to avoid the danger—instead, the device’s firmware and installedoperating system can possibly be reinstalled through other means such as those outlined in the section entitled “Regarding how to obtain software”. Any alternative means should be evaluated according to whether the alternative means are practicable and whether they are less dangerous.
Is factory resetting of devices sufficient for removing malware even when there is no risk of MITM attacks happening during the factory resetting? Unfortunately, it is not sufficient in all cases. Whenever malware has infected the BIOS/UEFIfirmware, there’s a chance that factory resetting will not be sufficient to remove the malware[15].
An irritating thing about a factory reset can be that it wipes all of your stored cookies. In order to retain your cookies, try using a backup and restore utility for your cookies[16].
Qubes OS 4.0.3 and Chromebooks specifically use sandboxing to mitigate risks in softwaremalware. The concept of sandboxing can, to a certain extent, be extended to cloud computing where there is software isolation based on server-side processing in the delivery of software that on the client (user) side, only requires thin client software (sometimes the software is simply a web browser). This essentially shifts the problem of end-usersecurity to one that is largely a server-side security problem, which is easier to handle in certain respects. Please note though that cloud computing can present new security risks, such as those related to storing your data remotely rather than locally.
You may wish to run your software using cloud computing resources, and interface with the software just using thin clients, as a possible way to improve your security. For example, you could create an Oracle CloudLinux compute instance, install Linux software on it, run the software remotely, and then access the software’s GUI using an x terminal (thin client) run on the client side. An alternative simpler way to ‘cloud compute’, is simply to use a Chromebook in conjunction with the many web-based apps available for ChromeOS.
Footnotes
↑Perhaps in an almost full-proof way by the judicious use of epoxy resin on the motherboard to encase certain key parts (such as pins and chips).
↑Such products are partly dealt with later on in the section entitled “Tokens for keys”.
based
