text:
Canadian Refugee Procedure/Decorum

All refugee proceedings have ritual, ceremony, and behaviour that is considered to be proper decorum. A ritual is a frequently performed action conducted in a predetermined order. The ritualized activities during hearings help decision-makers uphold authority in the process and bring a sense of solemnity to the situation. Decorum is "behavior in keeping with good taste and propriety." What is proper decorum in the context of refugee hearings at the Immigration and Refugee Board of Canada?

The Member should foster the appropriate climate for the hearing
Persons who are designated to act as Members represent Canada to claimants. They are seen to represent Canadian society and its core values. They must therefore behave in such a way as to preclude any suggestion that Canada is not willing to accept refugees, even though it reserves the right to make sure that they are acting in good faith. The following has been held to be applicable to Members of the IRB: the judge will ensure the climate necessary for the operation of justice by his moderation, his discipline and his courtesy in his relations with counsel, the parties and the witnesses. Because the claimant is not "on trial" and is merely seeking recognition of the claimant’s status as a Convention refugee, the panel has to try to put the claimant at ease as much as possible. The Member and IRB registry staff can be expected to treat the hearing participants with respect. This also has implications for the conduct of parties, counsel, and witnesses; a panel should not allow any participant to use abusive or threatening language, for example.

The claimant should be received and introduced to the hearing room by a Board staff member
Claimants should be properly received at the beginning of the hearing. The IRB commissioned a report on its use of videoconference and the resultant report stated that "From a justice system perspective, it seems to me wrong that claimants attending a hearing in which their future is to be decided by an adjudicator in what is effectively a judicial proceeding, should not be received in the hearing room at the outset by a real person with official status, who can address the claimants by name, confirm that they are in the right place, introduce them to the equipment, explain what to expect, and so on." That report, which is published on the Board's website, identifies this as an important step in the creation of a receptive and comfortable hearing environment. There is also an aspect to which the order in which the participants arrive at the hearing signals hierarchy and status: the Member usually enters last, something that requires the other participants to wait for the decision-maker to arrive.

Proceedings will be recorded
Audio of refugee proceedings before the Board will, as a matter of course, be recorded. Indeed, there is some legal risk where the Board does not record the hearing: Canadian Refugee Procedure/The right to be heard and the right to a fair hearing. International norms regarding refugee determination provides that states may record a refugee claimant's oral statements, but the claimant should be given due notice that this may be required. Such notice is a common way to begin proceedings at the RPD, where the member will, as part of an introductory spiel, inform the claimant that they are now "on the record".

Proceedings are a mix of formal and informal
Section 162(2) provides that each Division must deal with proceedings as informally and quickly as circumstances permit, taking into account the requirements of fairness and natural justice. This provision implies that the Division is not bound by formal rules of procedure that would apply in a court or more formal quasi-judicial tribunal. This accords with the recommendations of Rabbi Plaut, whose report led to the foundation of the Immigration and Refugee Board. In his report Refugee Determination in Canada, he stated "The atmosphere [of the refugee hearing] should be relaxed and informal and every effort should be made to put the claimant at ease". The Member is not, properly speaking, a judge, and should not be referred to with the appellation "your honour". It is generally recommended that the Member be addressed as “Sir” or “Madam”, although the non-gendered “Member” followed by the person’s last name is also common.

The Irwin Law text Refugee Law notes that "despite the Board's own description of its hearing process as 'informal,' the reality for claimants is that it is decidedly formal." Similarly, the Law Reform Commission of Canada, in its report The Determination of Refugee Status in Canada: A Review of the Procedure states that "Hearings are conducted...in a fairly formal atmosphere, in a quasi-judicial context which many claimants appeared to find intimidating. This formality flows from both the setting and the behaviour of the participants. The hearing room is laid out like a court room, with a raised desk and high-back chairs for Members. The style of proceedings is typical of that for a quasi-judicial tribunal." The Board has stated that panels have to ensure that a certain degree of decorum is maintained in the hearing room. It states that decorum is necessary (1) so that the claimant will appreciate that the panel is taking the process very seriously, and (2) so that the claimant and other witnesses will appreciate that the hearing is not a just casual interview, but rather is a serious "judicial" type of proceeding, at which every statement must be made as carefully and accurately as possible.

In operation, a refugee hearing is not dissimilar to any other administrative hearing: the parties are present, witnesses are examined, and submissions are made. Some of the expectations for conduct at such hearings follow:

Parties will wear attire appropriate for a formal hearing
The Board states that "attire should be appropriate for a formal hearing and in keeping with the atmosphere of the hearing room." Similarly, the guide for designated representatives provides that "In-person hearings are often held in a formal hearing room. Participants are expected to dress professionally."

The parties should stand whenever the Board Member enters or leaves the hearing room
The parties should stand whenever the Board Member enters or leaves the hearing room.

Witnesses will swear or affirm to tell the truth
A refugee claimant is required to appear and testify under oath. Evidence is typically presented in viva voce form at the hearing. Witnesses are sworn or affirmed and then questioned.

The panel will use accessible language to explain the procedure
The Member should put the issues in colloquial or plain language for the claimant, especially where the claimant is unrepresented by counsel or seems unsure of what is going on. See also: Canadian Refugee Procedure/Principles for the interpretation of refugee procedure. The fact that the Member turns to the claimant at the beginning of the hearing to explain what will unfold is something done with the ambition of making the asylum claimant feel comfortable. It is observed that by doing so, this this attempt to set the claimants at ease may reinforce the separation of the frequent participants and the asylum claimant, the “insiders” of the rituals from the “outsiders”, as only the outsiders require an explanation of the ritual activities.

Witnesses will put away notes while testifying
It is expected that witnesses, including claimants, will not have notes, their BOC form, or other paperwork in front of them while testifying. Such an expectation has generally been held to be compatible with a fair procedure.

Counsel will act consistently with their role and professional obligations
Counsel and independent designated representatives representing a party should adopt a professional and respectful approach. As noted above, counsel should comply with their professional obligations, something which has implications for comportment and conduct during the hearing. The Board has stated that this would enjoin the use abusive or threatening language, for example. Furthermore, the Board's guidelines for proceedings before the IRB involving Sexual Orientation, Gender Identity and Expression, and Sex Characteristics provide that questioning should be done in a sensitive, non-confrontational manner. This would appear to apply equally to counsel for the claimant, Minister, and any other participant, as it would to the Member.

Lawyers are - among other things - officers of the courts and have a duty to promote the interests of the state and maintain the authority and dignity of the courts. This arguably has implications for lawyers appearing before tribunals, not just courts. For example, the Code of Professional Conduct for British Columbia of the Law Society of British Columbia provides that lawyers should take care not to weaken or destroy public confidence in legal institutions or authorities by irresponsible allegations. Lawyers have a right and, arguably, a duty to criticize tribunals in some circumstances but such criticism must be measured against the public’s reasonable expectations of the lawyer’s professionalism. See also: Canadian Refugee Procedure/RPD Rules 14-16 - Counsel of Record.

This also has implications for the arguments that counsel advances. In Naqvi v. Canada, the Refugee Appeal Division concluded that counsel had advanced "callous arguments [that] attempt to normalize, justify, and condone domestic violence" in a case about whether the appellant was excluded from the refugee regime by reason of his past domestic violence, and it labelled such arguments both "concerning and inappropriate". In Awonuga v. Canada, the court commented that caution should be exercised by parties and decision-makers alike to avoid casting a broad, disparaging light on countries in the global south by suggesting that their peoples and institutions somehow lack the competence to produce documents in a professional manner. Counsel's role is to exercise judgement regarding a file and not to advance any argument that their client requests. See: Canadian Refugee Procedure/RPD Rules 14-16 - Counsel of Record.

Decisions
The Refugee Protection Division rules provide that a Division member must render an oral decision and reasons for the decision at the hearing unless it is not practicable to do so: Canadian Refugee Procedure/RPD Rules 3-13 - Information and Documents to be Provided. In practice, most positive decisions are provided orally and most negative decisions are reserved and provided at a later point in writing. Either way, following the hearing the parties will receive a written confirmation of the decision, along with a copy of the reasons for it in almost all cases: Canadian Refugee Procedure/RPD Rules 67-68 - Decisions.

It is typical for the decisions themselves to use language that implies some distance from the parties, for example referring to the refugee claimant as "the claimant" or "the appellant", and not by name.

title: Canadian Refugee Procedure/Decorum


text:
End-user Computer Security/Preliminaries

 = 𓆉 ≅

 End-user Computer Securitysim Inexpensive security

 * Preliminaries

 * Meta information
 * Table of Contents
 * Index
 * Foreword to first version

 * Main content

 *

 * Security of BIOS/UEFI firmware
 * Custom BIOS/UEFI and which one to use
 * Regarding operating system
 * Which OS?
 * Qubes OS 4.0.3 side-by-side with other operating systems
 * How to ensure installed operating system is not compromised via an evil maid attack, during periods when machine is not meant to be on
 * Regarding how to obtain software
 * Secure downloading
 * Getting an uncompromised smartphone and obtaining software with it
 * Key advantage
 * Downloading to SD cards
 * Transferring downloads to installation media
 * Cost
 * Old or new phone
 * Some other advantages
 * Similar to ‘burner phones’?
 * Whether to use a Raspberry Pi Zero device instead
 * Pros vs Cons
 * Pros:
 * Cons:
 * Conclusion
 * About using a Wi-Fi enabled SD card
 * Detection of malware in software
 * Compiling from source
 * Reproducible builds
 * Using `diff` utilities
 * Full system encryption, full disk encryption (FDE)
 * Malicious sneaky replacement of FDE system with historic clone of system that has known vulnerabilities
 * Description of attack
 * Remedy
 * Bootloader for FDE
 * Factory resets
 * According to device type
 * Web client computers
 * Smartphones
 * Conventional laptops
 * Some other issues
 * Internet connection during reset process
 * Sufficiency
 * Cookies
 * Sandboxing and cloud computing

 *

 * Password security
 * Password managers
 * Multi-step authentication and multi-factor authentication
 * Non-Latin alphabet
 * Concerning certain password attack vectors
 * Screen privacy
 * Keyboard privacy
 * Visual spying of keys pressed
 * Complete occlusion
 * Distance-dependent occlusion (privacy keyboard screen)
 * Using morse code
 * Spying of electronic keyboard signals
 * General visual spying
 * Hiding materially-written passwords
 * Overcoming vulnerabilities in visual encodings
 * Psychic spying of password
 * Protection using password management functionality
 * Protection by thinking little
 * Protection using password encryption
 * With technology
 * Without technology
 * Based on password reuse
 * Digital cryptography: security certificates, keys & tokens
 * Disabling TLS security certificates
 * Making sure certificates are genuine
 * Key servers
 * Cross authentication
 * Non-compromised communication of public keys
 * Sending to trusted recipient such that the recipient can hand it over without encountering MITM vulnerabilities, to the end-user
 * Publishing public keys in a “gazette”
 * Piggy-backing over bank transactions and systems
 * Using bank references
 * Using different monetary amounts
 * Using a weak currency
 * Google Authenticator “key and time”-based app for security
 * Tokens for keys
 * External links for further information on security certificates
 * Backing-up security keys and passwords
 * Shamir's Secret Sharing

 *

 * Wired vs. wireless
 * Shared WiFi
 * Keep communication systems turned off

 *

 * General security risks in digital storage
 * USB devices vs. SD cards
 * Flash memory: NOR flash vs NAND flash
 * NAND flash memory vs magnetic storage
 * Magnetic storage: tapes vs. discs
 * Rewritable media vs optical ROM discs
 * SD cards and USB memory sticks vs. larger devices
 * Drives able to eject hardware-less media vs. other media
 * More about SD cards
 * How to obtain computer media devices
 * Secure data sanitisation

 *

 * Physical isolation and locks
 * Physical measures for securing boot-loader when using full-system encryption
 * Padlock-able laptop bag
 * Metal boxes
 * Combination lock briefcase
 * Physically removing storage component(s) from the rest of the computer system, and then securely storing those components separately
 * Physically securing keys
 * Privacy screens
 * Specifically for goods in physical transit
 * Exploiting unrepeatable patterns for tamper evidence
 * Applying glitter nail varnish to computer screws
 * Tamper-evident security-system ideas
 * Main idea
 * Speculating stronger security again with unrepeatable-pattern principle
 * Similar idea for other circumstances (such as for metal boxes)
 * Perhaps the simplest and best idea
 * Software based tamper checking using security images

 *

 * ‘Inception’ styled attacks

 *

 * Put computer to sleep when not at it
 * Shut down device when not in use
 * Play sound continuously on computing device

 *

 * Stop funding the spies and hackers
 * Report cyber-crime to the police
 * Think in terms of gradual movement along a security-level continuum
 * Minimally-above-average security
 * Publishing security methods
 * User randomly selecting unit from off physical shelves
 * When random is not random
 * Ordering many units of same product
 * Using multiple channels to obtain product
 * Discerning unit least likely to have been compromised
 * Measuring physical properties for authentication
 * Weight
 * Volume
 * Magnetic weight and images
 * Electric field imaging/detection
 * Electro-magentic spectrum
 * Visible spectrum photography
 * Infra-red scanning
 * X rays
 * Microwave testing
 * Radio frequency (RF) imaging/detection
 * Ultrasound
 * Other methods
 * Geospatial
 * Based on which region
 * Time based
 * Based on time passed
 * Example 1
 * Example 2
 * Vulnerability when used for software
 * Based on time taken to forge
 * Using most secure window of time
 * Preventing lapses in security
 * DIY security principle
 * “Destroy key when attacked”
 * Relying on high production cost of certain security tokens

 *

 * Backing-up files
 * When to change digital passwords and keys?
 * Further information

 *

 * National Cyber Security Centre
 * Cyber-security standards
 * Deep hardware hacking
 * Cryptocurrency security
 * Using phones and computers as motion detector alarms
 * Steganography: easy hiding of information in computer documents

 * Appendix

 *

 * Cryptocurrency-like mining to increase trust
 * As applied to software
 * As applied to public digital keys (including those used in security certificates)
 * Lock screen with related sound-based security
 * Client-server noise-audio-based secure-password-communication system
 * Port source code to higher-level programming language as a computer-security step having its basis in secure coding
 * Security by pre-loaded private key

 *

 This book was first produced in response to a computer hacking incident encountered during 2020 by the author of the first version of this book, in the course of his being a self-employed software developer. He had already adopted some security measures but then felt he really needed an overhaul of the security measures and systems he had in place.  This book is aimed specifically at individuals, sole traders, and small businesses, bearing in mind that they may have shoestring budgets.  It was the author’s belief that end-user security was a real issue of concern because the mindsets of security specialists seemed to be often attuned to examining and proposing solutions within rigid frameworks: such as for example only looking at software security risks but completely ignoring physical aspects of everyday nuts-and-bolts security. A certain element of being able to think ‘outside the box’, and outside one’s own specialised domain, is needed. As such, security is really a multidisciplinary field, requiring the creativity of people from all walks of life.  There is special concern for the highlighted entities (individuals, sole traders, and small businesses), because of their being prone to attack due to budget constraints, and a lack of other important resources.   The author of the first version of the book places his contributions into the public domain (the author’s Google Drive version hosted here [minus the Google Docs comments] will always be in the public domain). He feels that end-user security is so important, that intellectual property obstacles should be removed as much as possible, so as to enable everyday users to be able to undertake computing activities safely. This is especially of concern at the time of writing during the 2020 COVID-19 worldwide outbreak. During this outbreak, individuals are being called upon in great numbers to remote work and also to socialise and conduct recreational activities using computing devices.

 The increasing consumer use of cryptocurrencies is another reason why a work like this is important.

 The author only asks in return that you, if possible, do the following:
 * Amend this work to fix mistakes.
 * Add comments indicating your level of agreement or disagreement with different parts that you read/review.
 * Improve it in other ways.

 Please note that because using your contributions might require that you grant copyright permission for such, it is mostly preferred that you make your contributions to the Wikibooks version of this book.

 Footnotes

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
End-user Computer Security

= End-user Computer Security =

 Inexpensive security for  ⦾ individuals,   ⦾ sole traders,   and  ⦾ small businesses

 First version written by a single author in April 2020.

 Footnotes

title: End-user Computer Security


text:
SPARQL/Templates

Within Wikidata Query Service Query Helper the comment #TEMPLATE can build a simple template where the user can choose one or more variables to change a query without needing to know the SPARQL query language.

See below an example to select presidents and their spouses from any country:

The "template" contains the texts and one ore more variables. The "variables" list the variables and optionally a "query" to select possible values, in this case ?id is instance of country.
 * If no query is needed the syntax is "?var1":{} In that case that might be

#TEMPLATE={"template":"Presidents of ?country and their spouses","variables":{"?country":{} } } Mind: BIND(wd:Q30 AS ?country) is used as a default for the variable ?country.

title: SPARQL/Templates


text:
End-user Computer Security/Main content/Software based

 = 𓆉 ≅  End-user Computer SecurityInexpensive security

=

 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.

 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 (in the section entitled “Compiling from source”).
 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.

 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 (go to 29m: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 (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.

 Trammell Hudson said that reproducible builds are important in his 2016 33c3 talk, the video of which is hosted here [go to time 31m: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 (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.

 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


text:
End-user Computer Security/Main content/Passwords and digital keys

 = 𓆉 ≅  End-user Computer Security Inexpensive security

=

 Password security is a very important issue as nowadays, it is not at all uncommon for users to be maintaining many accounts, some of which may be providing extremely important functionality, and that each require their own security credentials. Additionally, another reason why it is important, is that it is often good practice, and sometimes even contractually required, that users change their passwords on a regular basis. All these things put together, can appear to constitute something of an ordeal when it is remembered that users somehow have to keep secret and ordinarily also be able to call to mind, all of their passwords, which could potentially be very many.  In these respects, it seems prudent that an overall password security strategy be developed.  General information from the National Cyber Security Centre (NCSC) on password security is available here. Information and guidance from the NCSC on what makes a good password is available here.

 Google allows passwords to be stored in your Google account. A user can log into their Google account so that the account providing the settings of their Chrome internet browser, is the Google account. The Google account can then store very many different passwords, for different online accounts, that no one actually knows (it can be set so that even the user doesn’t know them). These passwords can also be randomly generated so as to create strong passwords, again, that no human being knows. When the user goes to the login screen for one of their accounts, where the password for the account has been saved in the manner just described, the Chrome browser automatically fills-in the password for the user, without the user having to call to mind the password or even to know it. In this way, a user can have different strong passwords for their different accounts, that can easily be changed, without any human being actually knowing any of the passwords.  There are other downloadable tools that also have this kind of password management functionality.  National Cyber Security Centre (NCSC) information and guidance on password managers (aka password vaults) is available here and here.

 (multi-factor authentication is also known as MFA)

 The security of passwords is ordinarily enhanced by using either multi-step authentication, or multi-factor authentication (MFA). The ‘multi’ aspect is often two (i.e. two-step authentication). MFA is a means for overcoming mind-reading attacks.
 When Google’s two-step authentication is set for a Google account, so that two-step security is used every time the user logs into their Google account, it in a way, to some extent, translates to a two-step level of security for those online accounts of theirs, that exclusively have their passwords stored in the user’s Google account using the secret way outlined in the previous subsection. Google offers a variety of second steps in their two-step security authentication settings, including USB security key token and text message.
 The National Cyber Security Centre for the UK (NCSC) recommends that users set-up 2FA (two-factor authentication) on all their important accounts. More information and guidance from the NCSC on multi-factor authentication can be found here.

 Computer password security can be enhanced by using an alphabet not so well known for the password. Non-latin alphabets will likely fit this description. It's probably best to mix several different alphabets together, for maximum security. This might be easier than initially thought, because within certain familiar domains such as mathematics and science, letters from foreign alphabets are often used (such as from the Greek alphabet). Choosing letters that have uncommon pronunciations may provide further security. Unicode non-verbal symbols and word symbols can also perhaps be used, including emojis, to increase security even more.

 The Chrome browser software unfortunately (at the moment) displays suggested strong passwords on the screen, which is open both to psychic attack and VDU signal interception attack. To overcome these attacks, simply move the Chrome window so that when Chrome tries to display the password, the displaying occurs outside the boundary of the screen, thereby preventing it from being displayed.
 As detailed later in the subsection entitled “Privacy screens”, privacy screens can be used as a defence against the spying of the visual emanations emanating from your screen, which can have the knock-on effect of interfering with illicit password-capture attempts.

A cardboard “restricted viewing enclosure”, with room for hands, can be constructed to go over keyboards. Once placed over keyboards, the user must look through the two eye holes (like looking through goggles) or some other kind of narrow viewing port, to be able to see the keyboard. User then places hands through hand holes, and types their password. In such ways, casual onlookers as well as cameras (hidden or otherwise), cannot see what is being typed, because the cardboard construction prevents such seeing, through visual occlusion formed by the cardboard.

 Example cardboard “restricted viewing enclosure” installed on Chromebook

 Partially-closed laptop for keyboard-typing privacy

 Another way to provide a level of occlusion from spies relying on spying of the visible spectrum of light, is to move physically, your computer and/or its parts accordingly. In the case of a laptop, this might involve partially closing your laptop (moving the screen closer to the keyboard based on pivoting around the laptop’s hinge[s]) but not so much so as to trigger the automatic powering off of the laptop.

 Using the reflective material commonly found in the lenses of sunglasses, you can create a short table of sorts (perhaps 10cm to 20cm tall) to go over your computer keyboard. Hopefully, when you type with the table installed, you must move your eyes close to the table surface to see which keys you are pressing. The hope is that from too far away, all you see are reflections, due to the special material being used for the table’s surface. By installing such a feature, you will better prevent cameras from recording your keystrokes. This could be very useful if you travel and spend time using your computer in different hotels where secret cameras could easily be installed. It is not certain that this will work, but it appears likely that materials with such transparency and reflective properties really do exist; so far no information on them has been found through internet searching. Perhaps another way to achieve the same effect, is to use glass or see-through plastic, that has very high glare properties. It is suspected that old CDs and DVDs can possibly be recycled to create such privacy screens. It is also suspected that material that is polarised and transparent, could quite likely help in creating such privacy screens.

 It should be noted that angle-dependent occlusion (rather than distance-dependent occlusion), as in restricting viewing angles, may also be helpful for establishing keyboard privacy. As such, the later section entitled “Privacy screens” is relevant to the subject of privacy keyboard screens.

 In conclusion however, for simplicity and ease, probably the best way to devise such a screen is simply to use a kind of pinhole material. For example, pinhole glasses are used by optometrists for the keratoconus condition, to identify vision in spite of the condition. From far away, the glasses just appear as small holes in some plastic. However, from close-by, being worn on an individual, an individual can see through the pinholes. The principle appears to be relatively straight-forward, based on the geometry of light rays as they pass from objects ahead of a viewer, towards the viewer. It is strongly suspected, such "pinhole glasses" material can be created by simply poking several holes through a cardboard sheet (which could provide a "low cost and home made" based advantage ).

One of the most straight-forward ways to counter the visual spying of the pressing of keys, is to resort to entering your password using morse code or some similar single-key password mechanism. A user can easily surreptitiously enter in their password using morse code whilst also having the appearance of writing something completely unrelated to entering a password. The user’s hands can additionally be placed so as to occlude the visual capture of the morse code being entered.

 Using a keyscrambler software, seems wise and a sensible countermeasure against the key logging of the electronic signals generated by keyboards. As outlined later in the section entitled “Psychic spying of password“, it is also effective against certain psychic attacks. Basically, what you type, say for example, for a password, is not what gets entered as the password—it is encrypted. Without knowing how to encrypt the key presses, it is impossible to know the actual password used, by means of conventional keyloggers.

 Hologram technology can be used for hiding passwords printed on paper, so that they can only be seen from certain viewing angles. Lenticular printing (which appears either to be related to holography or a type of holography) appears potentially capable of providing a cheap, mostly home-made, and DIY way to make holograms or something like holograms, capable of hiding passwords in this manner. Perhaps lenticular-printing security can be achieved simply by using something like corrugated plastic placed over a print-out from a conventional printer. Alternatively, passwords can possibly be hidden by them being printed on paper using ink that has slightly different reflective properties to the rest of the paper. When viewed from a certain angle, the hidden text will possibly be revealed due to the greater reflection of light from the ink, such that from other viewing angles, the reflection is not strong enough to reveal the text. Instead of using reflections, using other optical effects based on the use of transparent materials, perhaps can be employed for roughly the same thing. A reflective effect used in an opposite way, such that higher degrees of reflection effectively blot out the password and lower degrees instead reveal the password, may also be effective. Perhaps an even more interesting effect can be obtained if passwords are only revealed when monitoring all frames in the movement of an object. This could perhaps be done by rotating an object containing the hidden password, where the containment was such that the first frame shows just the first letter, and the last frame, at which time 180° rotation is achieved, shows just the last letter of the password. These kinds of effects appear to be possibly achievable with certain kinds of moving hologram, and also with certain kinds of lenticular printing.

 By using a UV pen, hidden things can be written that are not at all visible to the naked eye. Using an ultraviolet security lamp, ought to reveal such hidden things. But perhaps even more interesting, is that it seems UV protection glasses may also be able to see such hidden things. This effect appears to be widely accepted as a means for card players to cheat at card games like poker. To obtain such glasses, it might be best to order a pair of ordinary looking glasses (for the sight impaired), with the option chosen for them to undergo special treatment for protection against harmful UV rays; if you already use looking glasses, you may find that any extra expense incurred, ends up being inconsequential. Such invisible ink may be particularly handy for the paper-based keyboard scrambler mentioned in the “Protection using password encryption” section that shortly follows.

 There are also ‘classic’ old-fashioned steganographic ways to hide passwords, such as in a completely unrelated document by very weakly pencil-underlining the letters making up your password.

 The prevalence of camera technology likely means the very many types of visual encoding for passwords, can simply be recorded using camera technology with ease. Later computer analysis of captured images can assist in cracking passwords also perhaps with ease.
 Encoding passwords as flavours on a strip of paper, might overcome these vulnerabilities. If the paper can be designed so that it can only be 'tasted' once, then you have the advantage of being able to detect whether the password has already been 'read'. Technology to taste small 'dots' of flavour on pieces of paper, is likely not prevalent and is likely very expensive if it is at all possible (it might be possible with the aid of machines like GC-MS machines, but such machines are normally very expensive and require highly specialised skills that only a small minority possess). Once a flavour-encoded password has been 'read' (tasted), it can be destroyed if it is still able to be 'read'.
 Another potential way of encoding passwords to overcome sight-related vulnerabilities, is to use non-visible braille. The non-visibility aspect of the braille may be hidden by means of visual noise, or simply visual absence (of the specific markings used for the braille).

 The password management features of Google accounts also constitute one way of overcoming psychic password spying (basically, mind reading). Because only the 'computer knows' the individual passwords, psychic attacks simply don't work here so long as the security for engaging the password manager is not compromised.

 Passwords extremely well memorised, such that entering doesn't involve the conscious calling to mind of the password, is perhaps another way to prevent psychic attacks aimed at illicitly learning of passwords. If the password is called to mind merely as finger presses of keys, where exactly which key is pressed is hardly thought about by the key presser (where reliance is made on rote memory, rather than on conscious thoughts), probably it will be hard for those relying on psychic powers, to figure out what the password is.

 Another mechanism to protect against psychic attacks, is to have some piece of software on your local computer, that translates the password in your mind, into another one, where the other one is the one used to log-in (say to your Google account). Keyboard scrambling software is one such kind of software. Psychic attacks can get hold of the password in your mind, but because the real password for logging-in, is one derived from the software and your memory combined, the 'psychic attacker' can't get hold of the real password without also having the software. The software’s algorithm could perhaps be simply the concatenation of some never-known private key to the password called to mind by the user. In the case of any entity trying to force the account password out of you, destroying all the media on which the private key is stored, would effectively render recovery of the password ordinarily impossible. This kind of security feels like it might be aptly labelled as a kind of two-factor security system.
 Using a paper-based keyboard scrambler is perhaps a good idea to mitigate against psychic attempts to obtain your password. What you do, is you simply create a paper-based overlay for your keyboard, where the key characters and symbols are scrambled. You type your password as you remember it, into the scrambled keyboard. You then pack away your keyboard scrambler, perhaps even locking it up till the next time you need to use it. In such fashion, whilst a psychic attack might obtain the password from your mind, they will not actually know the password, because that password in effect has been encrypted through the paper-based scrambler. In fact, if you don't memorise the paper-based scrambler, then not even you know the true password, which seems really good. It's important to block the photographing of the paper keyboard scrambler, which can happen by means of hidden cameras. In this regard, folding it up when you don't need to see it, seems like a worthwhile precaution. A paper-based keyboard scrambler is particularly useful because of how much it costs to create. It's entirely feasible and economical to use a new cipher encoded in the scrambler, each week, by simply discarding the last paper-based keyboard scrambler, and making a fresh one. Also, the fact that it is not based on computer hardware or software, is another attractive attribute of this security measure.

 Example paper-based scrambler installed on a Chromebook

 For National Cyber Security Centre (NCSC) information on specific concrete passwords not to use (password blacklisting), see here.
 For NCSC security guidance and information in relation to a user reusing one of their previously used passwords, see here.
 For NCSC information on the password attack known as credential stuffing, that exploits the habit of users reusing passwords, see here.

 Why not turn off certain security certificates? This seems like a prudent measure. Not all certificates are to be trusted with the same level of trust. Also, it's likely that not all certificates are actually generally needed; in fact, perhaps only a small number of security certificates are in reality needed.
 How about disabling all TLS security certificates by default, and then selectively turning them on as and when they are required? Can even turn them off once they have been used. This should help to detect attempts at fraud and/or spying over the HTTPS protocol (and other like systems).

 Ensuring security certificates are not compromised, seems very important. To this end, multiple checks on them, perhaps in an automated fashion, seems like a good idea. Simply doing spot-checking to make sure that TLS security certificates on a particular device have the correct keys, by comparing them with the keys from another computer or source, may be enough.
 A user could export security certificates to an SD card and then when using a different system (such as a different WiFi network or different telecom provider), the user could then obtain differently sourced certificates, and check they are the same to the ones the user already has. Could be particularly applicable when in another country, as well as when visiting friends, etc. For example, in China, the government may tamper with security certificates, but users can then visit other countries, re-obtain the certificates, and figure out that the government is tampering with their security certificates.

 The notion of key servers seems very much applicable here—they can probably be used for verifying TLS security certificates, and generally speaking, they probably ought to be used for this and other types of digital key. Use of software such as GPG can be used perhaps to automate the task of key-server-based verification of keys. GPG apparently is available in the Heads firmware boot verification system (Heads was mentioned earlier in the section entitled “Custom BIOS/UEFI and which one to use”) —running GPG as hardware firmware may be best to minimise the risk of the software being compromised.

 Is there a way to get certification authorities to cross-authenticate certificates from other such authorities? Does it happen automatically? If not, it sounds like a good idea to have such a mechanism in place. For example, you may be able to discover that one certificate has been compromised on your computer, through the signed message of another trusted certification authority revealing what the compromised certificate’s key should have been. Relevant information on this subject might be found here.

 Communicating public authentication keys simply through website publishing might be considered as being not secure enough. The additional use of a key server, or maybe multiple key servers, may be useful for increasing trust in keys (which is touched upon above in the “Key servers” subsection). The novel Bitcoin-related method for increasing trust in public keys, described in the Appendix, may also be useful for improving user trust in published keys.
 However, what other ways can be used for communication of public keys?

 One possible solution is to get the organisation represented by the website, to send the key to a trusted recipient who can then hand it over to the end-user where in the handover there is no or virtually no possibility of man-in-the-middle (MITM) attacks. It might be ideal that the trusted recipient prints out the key, rather than for them to hand it over to the user as a computer file, in order to mitigate against security risks associated with computing technology. The user can physically travel to the recipient, rather than have the key posted or sent on to the end-user (thereby reducing transit risks associated with MITM attacks). A perhaps novel solution, that might be ideal, is for the trusted recipient to be an online printing business, such as Tesco’s, Kodak’s, or Boots’s photo printing. Several trusted recipients can be used to detect better, compromises in such communications.

 There is still the chance that an end-user’s request for such transmission to a trusted recipient is compromised through MITM attacks. To mitigate against this, instead of organisations doing such sending of keys on a per-end-user-request basis, the organisations can periodically do such key sending to key locations in the geographic areas of their markets. Doing such sending, is similar to simply periodically publishing the public keys in a well-known gazette.

 Another method of communication, that might be quite secure, is to piggy-back over the financial system's banking system. For example, the organisation can do a bank transfer for a nominal, trivial, and negligible amount to the end-user, with the bank reference being a public key to be sent. The end user can then visit a local bank branch, where the security is likely to be very high, and find out the bank reference used, and consequently the public key. Not only will the security at the branch be high, the security of the overall banking system is likely to be very high, thereby perhaps ensuring quite secure communication of the public key. To ensure that the transaction is genuinely from the organisation, perhaps your local branch can offer a service where they can give you useful company details of the account that paid you (such as possibly the company registration number, address of the registered office, etc.) You can then possibly authenticate that the source of the financial transaction was indeed the organisation. By ramping up the value of the transaction, perhaps further trust can be attained through the relatively high amount of money spent in the transaction.

 If it is believed that the bank transaction reference may be compromised, then reliance can instead possibly be made on the monetary amounts of transactions. For example, to send the key 1735 8513, a sender can make a series of 8 financial transactions: the first being for 1 pence, the second for 7 pence, the third for 3 pence, and so on. Because banks invest heavily in the financial integrity of transactions, this could be quite a secure way to communicate such information.

 Interestingly, using a weak currency could be better for such transactions, to bring down overall costs—perhaps a suitable cryptocurrency demonimination might be available in order to bring down the overall costs.

 A security method to mitigate against a certain type of evil-maid attack, involving the Google Authenticator time-based app system to ensure a computer has not been secretly replaced with another potentially compromised one, is described by Trammell Hudson in his 33c3 talk (it was previously described by Matthew Garrett). It is as follows. The key stored in the Trusted Platform Module (TPM) can be a private key only shared with Google. Then once you log into your system, the TPM essentially 'signs' the current time (rounded, perhaps to the nearest five minutes) with the key. Google then does the same through the 'Google Authenticator' system at their remote servers. In both instances of signing, the key is already with the respective party (so no transmission takes place, at that time, of the private key). The message digest created using the TPM is displayed on the computer screen; the digest created by Google, is displayed on the user's smartphone through the 'Google Authenticator' app. The user compares to make sure the message digests are the same. If they are the same, the user can be sure that an evil-maid attack hasn't occurred where the entire computer was secretly and deceptively replaced with another.

 It looks like USB-Neo tokens and -Neo-N tokens, in the Yubikey product family (produced by Yubico) can have their keys changed from a computer (like the Nitrokey product)   {see here for info on this}, which meets a requirement of having keys in such tokens different to those set when the tokens are sold off-the-shelf. Additionally and fortuitously, because the Yubico brand appears to be more popular than the Nitrokey brand, it appears that there's an increased chance that it will be found on the shelves of popular computer stores (such as PC World, etc.) {could be handy if employing principle detailed later on in the section entitled “User randomly selecting unit from off physical shelves”}. Also, they seem to be considered as being secure, with Google having mandated that all their employees use them for security. So it seems likely that generally, instead of opting for the less available Nitrokey product, one should instead get a Yubikey product that has the facility to have new keys assigned to it by the transference of them from a standard PC. If, for some user, it becomes or is such that the availability of Nitrokey products is the same or better than that of the Yubikey products, then it may well be better for that user, to opt for Nitrokey products instead, since in other more conventional respects, Nitrokey products do appear to be more secure.

 For National Cyber Security Centre (NCSC) guidance describing how certificates should be initially provisioned, and how supporting infrastructure should be securely operated, see here.

 The developer of the Heads firmware boot verification system (Heads was mentioned earlier in the section entitled “Custom BIOS/UEFI and which one to use”) has provided a potentially useful way to backup keys and passwords. He suggests splitting a key (or password) into say five different sections, and backing-up each section in a different way (perhaps by sending each section to a different friend). If recovery of the key is then needed, a threshold number of the sections can then be retrieved, and put together to recover the full key (perhaps in an automated way using specialised software.) The idea of splitting the key into several sections is apparently the basis of a cryptography algorithm known as Shamir's Secret Sharing. An interesting thought, is that Bitcoin wealth could potentially be backed-up this way, like creating a treasure map—perhaps it doesn't matter if it takes a year to trace the treasure using the treasure map, because the wealth is such that it doesn't need to be obtained straight away.

 Footnotes


text:
End-user Computer Security/Main content/Wireless Communications

 = 𓆉 ≅  End-user Computer Security  Inexpensive security

=   If internet connection is hacked, computers will become vulnerable. Although maintaining security on the user's machine will probably mean that security overall will be sufficiently maintained, it is still worthwhile safeguarding against such an event.

 Whenever there is a choice between wired or wireless communication (such as in the case of wired tethering for internet connections), wired communication is likely going to be more secure; it appears that most wireless routers usefully also permit wired ethernet connections.

 It's best not to use a shared WiFi router at all, if it can be helped; or if it is used, only to use it with a highly secure client-machine set-up. When a router is shared, it can be difficult to convince others about the need to perform certain security tasks, such as the changing of the WiFi password on a regular basis. Essex police’s cyber-security advice as of March 2020, was not to use free WiFi for anything you wouldn’t want a stranger to see.

 Keeping wireless technologies such as WiFi, Bluetooth, NFC, and infrared ports, disabled when not in use, is a good precautionary security measure.


text:
End-user Computer Security/Main content/Digital storage

 = 𓆉 ≅  End-user Computer Security Inexpensive security

=

 USB devices, SD cards, and drives (whether internal or external, whether a HDD, SSD, optical disc drive, or otherwise), including USB memory sticks, can likely easily be modified so as to transmit data to snooping devices—a security risk. Device ROM malware (using firmware or otherwise) likely always constitutes an attack vector for such devices (that appear often to have embedded microcontrollers that run such ROMs). The same applies with respect to hardware device tampering. However, SD cards are perhaps unlikely to undergo hardware tampering because of their small size (especially with respect to micro SD cards) and because of how they are constructed.  The custom BIOS/UEFI called Coreboot usefully has the option of being able to disable option ROMs when they are present in USB devices. If you use Linux in conjunction with such disabling, you can instead rely on the drivers supplied in Linux to interface with those USB devices —this approach objectively reduces the attack surface associated with those USB devices (because Linux drivers are considered to be more secure than manufacturer provided option ROMs that provide the same functionality) and is recommended for improved security.  Further information about such security weaknesses of USB and like devices, is available here on the Qubes website.

 At first, it was initially thought that SD cards had no firmware, such that they couldn’t be infected with firmware malware. However, as pointed out on the webpage hosted here (by Andrew "bunnie" Huang), SD cards do in fact have firmware as well as embedded microcontrollers that run the firmware. Therefore, firmware malware can be present on SD cards similar to how they can be present on certain USB devices. The webpage elaborates on these specific security risks.  SD card firmware is mostly a blackbox according to team Kosagi (in the video linked-to on the webpage), whereas USB device firmware specifications are generally more open and publicly available; this leads one to believe that from a purely programming perspective, it is easier to create malware for USB firmware (than it is for SD card firmware). Also, the team’s presentation in the video, inclines one to think that hardware interfacing for the purpose of reprogramming firmware, is much more difficult for SD cards than it is for USB devices. According to the team, it also appears it is harder to tamper with SD cards by sneakily adding or modifying hardware elements in them, than it is for USB devices (see same video ); their quite small size especially compared with USB devices, also supports such a conclusion. Because of these things, SD cards may generally have smaller attack surfaces in relation to both firmware reprogramming, and hardware tampering. Therefore, it may be best to assume that for higher security, if the alternative is USB storage, the use of SD cards is to be preferred for peripheral-based storage and retrieval whenever no extra special security measures are in place.  However, because the USB device firmware specifications are more open and publicly available, and because it appears to be easier to interface with a USB device for the purposes of checking and/or reinstalling firmware, it could in fact be easier to detect malware in USB devices than it is to do the same in SD cards. Reinstalling USB device firmware is often possible but the same for SD cards is generally almost impossible. So if you have a special process in place for ensuring the integrity of USB device firmware in the ways just touched upon, it may actually be more secure to use USB devices than to use SD cards.

 There appears to be some evidence that using NOR flash memory for storage (rather than the more common NAND flash) on USB and other devices, might offer a security advantage, most likely due to issues related to NOR flash apparently being better able to store and retain values in each of its cells. In contrast, NAND flash employs error correction algorithms because values are not so well stored in NAND flash cells (more of a probabilistic approach is taken). However, NOR flash appears to be mostly earmarked for things like BIOS ROM rather than general storage (and also rather than mass storage).

 Because in comparison to magnetic storage:

 Because it seems that objectively, random-access memory (RAM) has a greater attack surface in comparison to sequential access memory (SAM), it would seem that magnetic tapes are more secure than magnetic discs (magnetic discs are used in HDDs).

 "Write once" optical media is more secure than rewritable media because it narrows the attack window (and so also reduces attack surface) by generally significantly shrinking the window of time in which malware can be written to the media. It should be noted that if malware has already infected the firmware of an optical disc writer, even though you configure disc writing to be 'write once', because of the ROM malware, the writer may instead set the disc to be 'write many'. From this perspective, it is better only to use optical discs that physically cannot be rewritten, to write such media so that excess space is "blanked out", and to inspect visually, discs written, just after writing, to make sure that the excess space has indeed been blanked out; all of these things are important safeguards against attack vectors that specifically rely upon being able to make further writes to the disc.
 Optical ROM discs are also potentially more helpful compared with rewritable media, in relation to post security checking. Malware in the ROMs of memory sticks and SD cards, can mostly use the storage capacities of such devices unencumbered whilst also being able to eliminate all traces of malware from the devices, any time the ROM is run. However, the window of time in which such can happen for optical ROM discs, as mentioned in the previous paragraph, is mostly narrowed. By using write-once media, and taking the precautionary measures outlined in the last paragraph, the optical disc contents are frozen. If the frozen contents contain evidence of malware, that evidence cannot be clandestinely destroyed through your computer system once the disc’s contents are frozen. This means post analysis, even post analysis one year later, can potentially detect any malware that was on the disc, possibly leading to the identification of points of weakness in your security that are connected to the use of that particular optical disc. The same is not necessarily true with rewritable media because no such freezing takes place.

 Firmware integrity for larger devices is probably easier to establish because:

 larger device products (such as HDDs and DVD drives) tend to be kept for longer with fewer units tending to be used per user, when compared with SD cards and memory sticks, which means that not so many firmware checks overall need to be made.

 their relatively high price inclines one to believe that it is easier to ensure firmware integrity (because of increased support, better written firmware code, etc.)

 reinstalling and checking the firmware is likely much easier than it is with SD cards that are constrained due to their small form factors, and perhaps also when compared with memory sticks.

 Drives capable of ejecting hardware-less media (such as optical disc drives, tape drives and floppy disk drives) may have special advantages in respect to hardware and firmware tampering, due to users only needing to “keep their eyes” on one unit regardless of how many hardware-less media (such as tapes and discs) are used. This is not true for memory sticks and SD cards because these media are essentially hardware incapable of ejecting hardware-less media, in fact the concept of ejecting media from them doesn’t apply. It is also not true for hard disk drives since the discs in such drives cannot be swapped out for other discs.

 Team Kosagi in the video mentioned earlier, specifically names the manufacturer Sandisk as possibly creating more secure SD cards when compared to the SD cards of other brands. Their reasoning behind this is that extra security is achieved through Sandisk’s creation of SD cards having firmware that is not so reprogrammable (or even reprogrammable at all), due to Sandisk having higher involvement in the production process. Incidentally, SD cards can often be used for storing downloads made through mobile devices.

 It seems like a good idea always to use media devices that were bought in such ways that no significant risks of MITM (man-in-the-middle) compromises, were encountered in the acquisition of the items, and that were also bought from trusted shop sources. It might be preferable to buy such things from large shops, where you can choose any one device at random from a large selection of identical products from off the physical shelves (this is the security principle outlined later on in the section entitled “User randomly selecting unit from off physical shelves”).

 NCSC (National Cyber Security Centre) information on secure data sanitisation (rendering data unrecoverable) of USB storage devices and SD cards, as well as of other storage media and drives, is available here. Note that conventional data erasure may not work with storage devices (such as SD cards, USB memory sticks, external hard drives, etc.) because of the possible presence of malware in the microcontroller firmware of such devices, especially when the related microcontroller is also embedded in the device. In light of such, it may be necessary to destroy physically such devices to ensure better data sanitisation.

 Footnotes