# End-user Computer Security/Main content/Software based

End-user Computer Security Inexpensive security
| $^{for}$ | ⦾ individuals ⦾ sole traders ⦾ small businesses |
A computer may be hacked due to its BIOS/UEFI firmware being infected with malware (such infection occurring due to malevolent forces). This applies to smartphones, thin clients, and conventional PCs.
Because of this possibility, sometimes it is necessary to reinstall the BIOS/UEFI firmware.
A custom BIOS/UEFI firmware 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 flashing Chromebooks 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.
It seems that Coreboot can also be installed as the firmware for an Android phone.
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. 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.
* Which OS?
* The Linux operating system (OS) has a reputation for being more secure than the Windows operating system. Being able to compile Linux from source, and not being able to do the same with Windows, adds to Linux’s security, which is expanded upon later on in this document
* 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 systems
* 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 Linux operating 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:
* the BIOS,
* OR IF WISHING TO BE MORE SECURE,
* both the BIOS as well as by physically disconnecting the internal drive
* (this latter option might be a good idea to do because malware in a BIOS's firmware can still connect to BIOS-disabled drives).
* Boot off the SSD to run this other Linux.
* 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 on
* If:
* full-system encryption is used,
* the operating system has a high level of security,
* the risk of the hardware being or becoming compromised is very low,
* the bootloader is kept on a secure USB memory stick (or SD card) that is locked away when not needed,
* the password and key (as applicable) are made difficult to obtain (whether by password cracking or other means), perhaps with the aid of a USB security token product
* AND
* 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),
* 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-only live DVD 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”; however, be aware that system speed is often degraded when running the operating system in such fashion.
* Regarding how to obtain software
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, BIOS firmware, etc.) and at least in terms of part of the overall solution used.
The broad security principle(s) outlined in the “Ordering many units of same product” sub-section also applies.
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 internet downloading (such as certain firmware re-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.
The advent of smartphones appears to be of great benefit to this problem. It looks like a cheap uncompromised smartphone for simply downloading files 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 section entitled “Digital storage” in this document, provides information about some of the security issues surrounding the use of SD cards when using them in mobile devices for the downloading of software.
Getting the downloads on to suitable installation media for computing devices is perhaps something about which to think. It seems it is possible to get DVD burners and USB memory sticks for smartphones. You can also get USB adapters for the SD cards used in mobile phones. Many laptops have built-in card readers for interfacing with SD cards, and on such laptops, according to Wikipedia, it appears it is sometimes possible to boot off an SD card, which has the potential of greatly simplifying things. From brief internet research, formatting media used just for storage and retrieval (eg. DVDs with a DVD drive, memory sticks, SD cards, etc.) as bootable media, solely by means of an Android mobile device and the storage media connected together, is quite likely not very difficult to do. Bootable media is often needed when reinstalling certain classes of software. Please consult the section entitled “Digital storage” for further guidance on which storage medium to use.
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:
* things like security hole fixes,
* possible improvements in technology, AND
* some of the security certificates in the new phone likely being as new as possible for their respective class of certificate.
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, 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.
Interestingly, using so-called 'burner phones', seems to be closely related to the suggestions made in this “Getting an uncompromised smartphone and obtaining software with it” section.
It initially seemed that the most
* appropriate,
* inexpensive, and perhaps even
* secure way to download securely,
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, and then to use that device for downloading.
Pros:
* 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—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.
* Very cheap, priced at around £5 brand new.
* It is stripped down to remove many 'bells and whistles' that would otherwise introduce further risks.
* Doesn't have WiFi, which forces users to use a wired connection for the internet, which is more secure and actually ideal.
* The operating system that it uses is a Linux distribution, Linux is known to be relatively secure; also, because it is Linux and open-source, it should be possible to use it to do things like create bootable media using the Pi device, which may be needed for the re-installing of firmware and more generally, of compromised systems.
* 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.
* It has USB connectors for connecting memory sticks.
* It is freely open for visual inspection of its parts, which has been suggested as enabling easier detection of hardware tampering.
* safe,
* hidden location,
* tamper-evident container, or
* otherwise,
* might generally be cheaper.
Cons:
* Appears to require a USB keyboard. According to Micah Lee in the Qubes OS video hosted here $^{(goto29m:47s)}$, using USB instead of PS/2 for plugging in your keyboard, is something of a security risk.
* Appears to require a screen, which is a vulnerability. For example, if plugging into a TV, 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. Also, the related hardware somewhat reduces the advantage of removing unnecessary 'bells and whistles' (in other words, it reduces the advantage of keeping things simple and thus less risky.)
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 reprogrammable firmware “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 WiFi hardware 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 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.
Trammell Hudson said that reproducible builds are important in his 2016 33c3 talk, the video of which is hosted here $^{[gototime31m:07s]}$ (presumably for security reasons).
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.
`Diffoscope` appears to be a potentially useful utility for detecting malware introductions between released versions of closed-source software, when the “reproducible builds protocol” is being used in software compilation. The Wikipedia page on reverse engineering, implies that extracting the source code from such closed-source software, in an automated way, and then running `diffs` on the source code, likely can better uncover malware introductions.
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.
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
As was hinted at in the subsection entitled “How to ensure installed operating system is not compromised during periods when machine is not meant to be on, via an evil maid attack”, securely storing the bootloader away from the computer during periods when your computer should be in a powered-off state, is a good idea. The reason is that the bootloader, as stored in the computer system, is a potential attack vector. The Heads BIOS firmware system partly overcomes the traditional form of the attack by actually storing the bootloader in the internal ROM of the computer system, rather than on an internal drive (or as just suggested, externally, outside the computer system). It is not certain whether storing the bootloader (such as on an SD card) such that it can be locked away securely, is more or less secure than the solution presented by the Heads system. However, it is suspected that the Heads solution is more secure because otherwise the Heads creator probably would not have implemented it.
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.
With web client computers (like the Chromebook), it is likely that there are very few backup-and-restore concerns about doing a factory reset, because files are often mostly stored (and consequently backed-up) in the cloud.
With a smartphone, it might take longer to configure after each factory reset, but still should be relatively straight-forward to do.
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 , 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.
Internet bandwidth 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 installed operating 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/UEFI firmware, there’s a chance that factory resetting will not be sufficient to remove the malware.
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.
Connected with the concepts of physical isolation and locks, are the concepts of sandboxing and cloud computing.
Qubes OS 4.0.3 and Chromebooks specifically use sandboxing to mitigate risks in software malware. 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-user security 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 Cloud Linux 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
| Contents, Index, Foreword | Chapter 2 Passwords and digital keys |