text:
End-user Computer Security/Main content/Some measures that are primarily physical

 = 𓆉 ≅  End-user Computer Security Inexpensive security

=

 Physical isolation and locks are also other important elements in maintaining computer security. For example, locking-up a laptop when it is not being used, might be a good idea. If a laptop is left unattended for a long time, someone could perform major tampering to it, in such ways that there is no trace evidence of the tampering. Full-system encryption (dealt with in the earlier section entitled “Full system encryption, full disk encryption (FDE)”) can partially defend against this.

 Having the bootloader for such full-system encryption separately locked away on a USB memory stick rather than stored within the laptop as is usually done, may be a good idea from a security point of view (as documented in the earlier section entitled “Bootloader for FDE”). If the bootloader is instead kept on an internal drive (as is normally done), it’s relatively straightforward to tamper with the bootloader when there is physical access to the laptop (by use of so-called bootkits for example). If you are storing the bootloader in the laptop, and you choose to use the Heads BIOS/UEFI firmware system, you will have improved security because Heads stores the bootloader in motherboard ROM rather than on one of the internal drives. If in conjunction with Heads, you make certain judicious use of epoxy resin on the motherboard, it appears likely that tampering with the bootloader can be made extraordinarily unlikely, ensuring such good security in conjunction with full disk encryption, that it may even be unnecessary to lock away your laptop.

 If you have a laptop bag, have a look to see whether you can padlock it, perhaps through zipper sliders on any of the bag’s zips. Also consider whether you can padlock all of your computing devices within that bag, for safe-keeping. You may, for example, be able to padlock your laptop, Chromebook, and mobile phone, all within that bag. When you take your devices away from your usual work location (such as when travelling with them), you may wish to take the bag with you, and have your devices padlocked in that bag whenever they are not being used.

 If you are locking devices away in metal boxes, you may wish first of all to place them in cushioned bags (such as perhaps a laptop bag), in order to prevent damage from knocks and bumps when the devices are in the metal boxes.  Metal boxes can probably be securely obtained, by buying them over the internet and having them delivered to you, because there are unlikely to be security concerns if they are intercepted—they can be manually inspected when they arrive to check for tampering. But it should also be borne in mind that, due to great advancements in espionage technology, detection of embedded espionage technology might not be so straight-forward as simply visually inspecting any such boxes. From this point of view, it may well be worthwhile purchasing such a box using the principle outlined later on in the section entitled “User randomly selecting unit from off physical shelves” to minimise the risk of espionage technology being embedded in the metal of the box. In contrast, the padlocks used for any such metal boxes likely should, without question, be bought using this principle in order to minimise MITM attacks (man-in-the-middle attacks) that are focused on the padlock element of the set-up. It probably should be ensured that the security ratings of the selected padlocks are all high.

 Computing devices may also fit into a combination lock briefcase that you already own. You might be able to purchase such briefcases cheaply from a local second-hand shop however, be aware that second-hand combination locks might pose unacceptable security risks for your particular threat model.

 Such securing may be good seeing as ‘data at rest’ on such storage components (such as on SD cards, internal HDDs, etc.) are mostly more secure than when in their associated computer systems, whenever reasonable physical security measures are also taken. The storage components can then be installed in fresh brand new non-compromised computer systems, to retrieve securely the associated data authentically. Also, such storage components tend to be smaller than computer systems, which provides for better secret concealment and storage. However, it should also be noted that because of their small size, they can also be secretly stolen more easily.  On some laptops, removing the internal system disk is easy. If you have such a laptop, you can perhaps simply remove the system disk at the end of each working day, and lock it up. This may not be feasible for laptops not having this feature (perhaps most or all light-weight computers, such as certain Chromebooks, fall into this latter category).

 It seems likely that someone can quite easily create clones of most physical keys by:

taking a short (maybe 10 seconds' long) mobile-phone video of such a physical key,

sending the video for computer analysis, and then

creating a cloned key based on that analysis.

 If this is true, then an adversary (or maybe perhaps more specifically an "evil maid"), just needs access to the physical key and a camera on their smartphone (most people have smartphone cameras) for maybe just 30 to 60 seconds for the creation of the video that is then sent over the internet perhaps half-way across the world, for computer analysis to create a cloned key.

 It may therefore be best to use tamper-evident systems (such as those detailed shortly in the next subsections ) to protect physical keys. However, it should be borne in mind that if the tamper-evident system employed relies upon padding consisting of something like rice grains, then an adversary may still be able to clone the key by simply using x-ray photography. With this in mind, using shredded CDs and DVDs for padding might be a good idea, as the metal in them will probably interfere with many photography methods that rely upon electric fields, and/or magnetic fields (covers electromagnetic radiation).

 A good idea seems to be to get privacy screen filters for your different devices. They work by inducing some level of privacy by lowering the maximum viewing angles of the screens on which they are installed.

 In order to ensure goods aren't tampered with in transit, it can be requested of the sender that they appropriately use tamper evident mechanisms such as certain kinds of security tape and certain kinds of security bag. These appear to be cost-effective ways to help ensure goods aren't tampered with when being sent by post. Unfortunately, from investigations, the current tamper evident solutions that are commonly available appear to be mostly quite poor. A novel solution might be to sign digitally a customer’s address, and then print such signature on the tamper-evident mechanism in such fashion that the mechanism is costly to duplicate (perhaps by use of some kind of supplier ‘seal’, maybe a holographic one, also printed on the mechanism). However, at present, no such product or other good enough product appears to be generally affordable.

 Collage illustrating the method of applying glitter nail varnish to computer screws on a Chromebook

 Trammell Hudson has suggested a low-cost and effective tamper-evident solution that uses the painting of computer-case screw heads with glitter nail polish to produce practically unrepeatable patterns that are destroyed through unscrewing. By photographing the patterns, and making sure patterns haven’t changed, one can be reasonably sure that no one has unscrewed the painted screws. Information on this solution, which seems to have been accepted by the security community, and how it can be slightly extended for other things, can be found here.

 In parallel with Trammell’s solution which is at least five years old, Mark Fernandes has recently devised similar schemes that employ the same unrepeatable-pattern principle. Those schemes, possibly with improvements contributed by others, are detailed in the following subsections.

 Note that creating your own home-made set-up out of commonly available materials (like cardboard) will likely ensure greater security.

 Submerge a computing device in:

⦾  polystyrene pieces    (such as those used for cushioning parcelled items [aka foam peanuts]),

⦾  rice,

⦾  transparent beads,

⦾  imitation diamonds,

⦾  shredded:

⦿  paper,

⦿  reflective foil,

⦿  holographic material,

⦿  redundant CDs and DVDs,

  (paper shredders are commonly capable of shredding CDs and DVDs)
 (such shreds might have reflective, refractive, holographic, and transparent properties)

⦿  transparent cling film,   OR

⦿  other transparent plastic

🄾🅁

⦾  a mix of any of these

 encased in a transparent plastic:

➢  box,    OR

➢  bag/pouch

 (a bag/pouch is good because the shape flexibility of the bag/pouch provides stronger tamper evidence).

(depending on means and security level desired)

 Due to the optical effects of refraction and/or reflection, increased security can be attained by using materials with high amounts of transparency and reflectivity.
 But when using reflective properties, care needs to be taken to make sure reflections of things outside the security zone do not occur in the photography as that might make the authentication of photographs not possible.
 Mixing different materials together, may provide the optimal solution.
 Highest security is likely plastic bag/pouch containing material with

 ◦ reflective, ◦ refractive, ◦ holographic,    and ◦ transparent    properties,
🄰🄽🄳
where those properties are varied amongst the pieces.

Take at least two photographs, each from quite different angles, with at least one from an aerial view, of the plastic container with its contents visible.

A tripod (even used with a mobile-phone camera) can be used, in the scenario that a static camera position-angle combination is required for the better detection of discrepancies between two security photos.

 Securely store the photographs so that they undergo no tampering

(you may wish to print them out and sellotape them to your body if you desire high security).

 After some period of time, return to the container.

 Check that the photographs match the current state of the container.
 Software (such as an app) may be used to automate security photograph matching however, it should be noted that simply switching back and forth between two photos on a screen, can be sufficient for a human being to detect visually, visual changes, due to the high visual cognitive power of human beings—it’s basically a game of ‘spot the difference’.

 A similar idea with potentially even more security may exist where a computing device is placed in a water-proof container, and then submerged in a bathtub of water that has coloured oil on the water’s surface such that there is a marbling effect on the water’s surface—admittedly, it’s not clear whether this other idea would actually work in practice.

 Another similar system relies on the likely fact that certain natural hand-made paper:

can be easily photographed,

is hard to duplicate as a deceptive fake in respect of the precise natural colour variations for a particular sheet of paper (they’re like fingerprints), and

is not capable of having significant tears in it hidden from those wanting to detect any tears in it.

 Where such properties are also found in other materials, such other materials probably can also be used instead.
 Any one such paper, can be 'read' by taking a photograph of it. The colour variations can be measured and in sequence encoded as a long number, which can also be interpreted as being a key (like an encryption key). With such a paper, it is practically impossible to create another paper with exactly the same colour variations, as a deceptive fake. The paper can be glued over the hinges and crevices of a locked metal box. By opening the box, the paper is torn. Because it is hard to hide tears in it in the case of someone else opening the box before you, and because the precise colour variations are hard to fake deceptively, you’ll notice whether someone else has opened the box before you, thereby providing tamper evidence.
 Very strong glue probably would need to be used, to ensure better that the paper is noticeably damaged through the opening of the box. If the paper can be glued on the inside of the metal box (instead of the outside), that might be best in order to prevent someone removing the glue through the use of glue solvents like acetone, the doing of which would present itself as a point of weakness in the security system if the gluing were instead performed on the outside.

 Perhaps the simplest and best tamper evident system is simply to wrap-up computing devices in some material that retains its shape when at rest, but that also can quite easily lose its shape when slightly disturbed in such fashion that it is hard to achieve once again the prior shape. Shell-suit material may be good for this. Also silk (maybe an old silk scarf perhaps) might be good. Certain kinds of crumpling plastic bags might also be good. Simply using bubble wrap in such ways, will likely provide at least some level of security.

 If relying on software based authentication for making sure there is no tamper evidence between two security photos, using a tripod is likely necessary as two security photos requiring comparison need to have been taken from the same angle and location (at least approximately within a certain degree of deviation). Using a smartphone camera may be preferred, as the software for checking two security photos can then be automatically run on the same device used for capturing the photos, which in some ways (in respect of being such an integrated approach) presents a more attractive security solution. However, a digital camera can also be used, with the associated SD card being then taken out and placed into a device that can run the related security-photo matching software.
 The software solution can be manually coded, if none already exists. A rough idea of an algorithm that might be acceptable for the solution, is as follows:

 If necessary, generate many security photo pairs, by using the first photo as the first element in each pair, and then by generating different and distinct second elements by re-positioning the second photo within a frame (solely in computational terms), by small amounts away from its original position, such that all re-positioning is tried in all the generated re-positioned photos, where re-positioning only occurs within a set radius from the original position of the second photo. Each of the generated security photo pairs should then go through the process outlined in the remaining steps in order to determine whether any security-compromise disturbance has occurred. This step is here to mitigate against the potential of the camera position used between two security-photo-taking events being slightly different (probably because of slight physical disturbances).

 Increase size of pixels in photos so that they look more pix-elated, but not so much so as to have the software fail of its essential purpose.

 Calculate standard deviation on colour differences (can possibly use Euclidean distance between two RGB values mapped to 3D space) between corresponding pixels in both photos (using this method requires that lighting be exactly the same between two security-photo-taking events, which might be contrived by closing curtains and switching on electric lighting).

 Make sure standard deviation is beneath a certain toleration level, where such bounding implies that there were no physical-disturbance-based security compromises.

 Footnotes


text:
End-user Computer Security/Main content/Simple security measures

 = 𓆉 ≅  End-user Computer Security Inexpensive security

=

 When not at your computer, it may be a good idea to put it to sleep. The reason being is that if an intruder has remote control of your computer, and you only leave your computer locked when you are not there, without your knowing, they may start to do screen-visible things on your computer when you are not there. When you are at your computer, the intruder may be frustrated in trying to do such things because you are then monitoring your screen. So putting your computer to sleep when you are not there, may be a good idea in order to frustrate such remote-controlling activities.

 Shutting down your phone or other computing device before you go to sleep is probably a good idea—it’s an easy precautionary measure. Doing the same at other times when they are not much needed, might also be a good idea.

 A simple security measure to monitor whether someone, with physical access to your computing device that is near to you:   ⦾ has taken it away from you,       🄾🅁   ⦾ is shutting down or rebooting the device

 (as well as maybe doing some other things to the device that potentially compromise security)
 is simply to play some continuous sound on it that is heard through its speaker. This could be simply playing the radio on the device. If someone then were to take it away from being near you, normally you would notice the absence of, or lowering of volume in, the sound (due to the greater distance of the device from you). Also, if someone were instead to shut down or reboot the device (perhaps as a precursor to tampering), normally you would notice that too because normally the sound would disappear.
 Do note though, it could be possible to replace the sound playing on your device with the playing of the same sound on another device, such that you don’t notice the occurrence of any of these security compromising actions. In light of such, it may be good to play sound that is hard for others to reproduce precisely, perhaps something as simple as music from your own personal favourites playlist.
 Obviously when using these measures, screen locking should also be employed.

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


text:
End-user Computer Security/Main content/Broad security principles

 = 𓆉 ≅  End-user Computer Security

Inexpensive security

=

 As hinted at in “Desktop Witness” by Michael A. Caloyannides, we may well be mostly inadvertently funding the work of spies and hackers, by purchasing personal computing resources without investing reasonable efforts into securing and securely using such resources. So whenever budgeting for computer resources, also factor-in the efforts required to keep and use such equipment securely—you don’t want to be the worse-off because of computer resource purchases you made.

 Reporting crime to the police doesn’t only potentially obtain for you, free and tailored computer security assistance from authorities. It also helps to prevent crime in general such that there may be fewer criminals around in the first place to attack your systems, perhaps simply because they have been warded off from committing any crime due to your prior involvement of the police.

 Security isn’t simply a question of a Boolean secure-or-not-secure proposition. There is a continuum of security levels, from least secure to most secure. Instead of thinking in terms of simply needing to be secure (which is certainly something worthy of your aspirations), think in terms of progressively moving along the continuum, day-by-day, gradually getting more and more secure, on the whole. Such progressive movement makes sense in terms of balancing the risks of security compromise with the efforts required for becoming secure. Also, don’t be concerned about ‘over doing it’—it’s not an exact science, and it’s often better to do too much than to do too little. Also, don’t worry about mistakes too much; so long as they’re not too frequent, fail-safe mechanisms in your security, coupled with threats being probabilistic, will mean that they won’t matter that much.  The National Cyber Security Centre for the UK (NCSC) touches upon this principle in their blog post entitled “Not perfect, but better: improving security one step at a time”.

 A security principle exists, where entities seek security levels that are minimally-above-average security. The rationale behind such an approach is as follows. It is supposed that adversaries have in their arsenal of weapons, attacks that overcome average security levels, but not attacks that can do much more. They maximally target users such that the “hacking success to work done” ratio is roughly optimal, which generally means constructing attacks that can be reused as much as possible (to save on work done). Then for every extra unit of work done, the ratio diminishes, equating to less “bang for your buck” (for the hacker). So to defend against such adversaries, an entity may choose to implement security that is above average, but only so much so as to defend against such adversaries who look more for common security weaknesses amongst users as a whole, rather than being able to hack the most secure of systems (“Fort Knox” like systems).  The National Cyber Security Centre for the UK (NCSC) touches upon this principle in their blog post entitled “Not perfect, but better: improving security one step at a time”.  Some NCSC information on the behaviours and characteristics of cyber crime and cyber criminals can be found in their report located here.  It might be that Trammell Hudson also agrees with this principle since on his website, he sometimes uses phrases such as “slightly better security”.

 It may seem counterintuitive to publish your security methods. However, doing so can actually increase your overall security (rather than decrease it).  Firstly, by publishing your methods, you can get useful feedback in respect of the weaknesses and strengths of your current security methods, and then adjust them accordingly.  Secondly, your activities are unlikely to be completely isolated; instead, they are likely to depend upon a number of relationships with other entities. From this perspective, improving the security of the wider community, can provide better security for yourself.  Thirdly and finally, the widespread adoption of better security methods, can make the aspect of hacking you more difficult than if only you adopt better security methods. Suppose you are a hacker and you have on your agenda to hack 100 entities. If just one entity improves their security, hacking your 100 entities perhaps isn't negatively impacted so much. However, if all 100 entities improve their security, then hacking any one entity is made even more difficult because the hacker has to bear in mind that they also have to allot sufficient resources (including time) also to hacking the 99 other entities—the hacker may become simply too stretched for time/resources.

 Getting a unit sent to you in the post is not necessarily the most secure way to obtain a unit of any particular product. In particular, obtaining units in such ways are vulnerable to man-in-the-middle (MITM) attacks.
 Instead, it may well be more secure to buy a unit by first physically visiting a large physical store selected at random, that is geographically distant from the user’s address, and then when at the store to choose and purchase personally, a shrink-wrapped unit fresh from its factory (or other product source) from off the physical shelves, using random selection, where there are many other units of the same product on the shelves.

 Behavioural cues can sometimes affect a person’s mental processes, or be used to read a person’s mental processes, such that trying to implement random selection solely with your mind, ends up with selection that’s not so random. In such cases, you should seek to generate random selection externally, which could be something as simple as tossing a coin or rolling some dice.

 Security can be increased by purchasing very many units of the same product. Because you have so many units in your possession, it should be more difficult for an attacker to tamper with every single unit. One unit can then be chosen at random, and all other units can then be returned for either partial or full refunds.

 Perhaps a good way to ensure a product isn't tampered with before use, is to obtain the product through multiple channels. For example, software can be downloaded, bought from a physical shop, and also bought from an online shop. The three versions of what should be the same installation software, once obtained, can then be byte-for-byte compared with each other to see whether they are exact copies—if one isn't, then it likely points to tampering having been conducted to one or more of them.

 If obtaining hardware, instead of using random selection, a potentially better way to select which unit to keep (one that hopefully hasn't undergone any tampering) is as follows. First, purchase several units of the same hardware. Once several units have been obtained—let's say for sake of example, seven units—the user needs to figure out which of the units have the least likelihood of having undergone any tampering, ideally without damaging them so that excess units can be returned for refunds (hopefully full refunds). To help in this figuring out, the user can use one or more non-invasive and non-destructive measuring methods, some of which are documented in the next section entitled “Measuring physical properties for authentication”.
 The measuring can be undertaken before opening the hopefully shrink-wrapped boxes that contain the units (to facilitate being able to return, later on, no-longer-needed units). The measurements that are most common amongst the units, determine the quality-control parameters. Then any one unit fitting those parameters can be selected. This selection process on the whole is better than pure random selection, as it is better able to sift out any tampered units that may be in the mix, by using a balance-of-probabilities approach—tampered units hopefully will have odd measurement readings. So for example, if 6 units have the weight 100g with only one unit having the weight 101g, you would choose not to keep the unit weighing 101g (the odd, and potentially tampered-with unit).
 Since the measuring techniques involved hopefully won't damage the units, returning excess units for a full refund should hopefully not be a problem.

 How do you confirm that a physical device in your possession is exactly the same as the device it ought to be, as it was manufactured? It could not only have undergone tampering, but it could in fact be an entirely different device that just has the appearance of the actual genuine device.
 Measuring physical properties appears to be a good way to make sure you have the genuine device in your possession. Whilst an adversary may be able to replicate one of the physical properties, the convolution (or intersection you might say) of several (or maybe even just two) is likely quite hard to replicate in any kind of imitation or tampered-with device. Once we acknowledge this principle is valid, we now turn to what physical properties we can measure for the application of this principle.

 Weight is something very easy to measure, so there are no worries about using it.

 In the case of devices incapable of being damaged by slow-moving water, to measure volume, we can simply measure the displacement of water by placing the device in water.
 In the case of other devices, if the device is low cost, a user can purchase two units of the device, one to be measured using destructive measures, the other one to keep, assuming the security tests succeed. The one to be measured, can have its volume measured in the same way as just outlined. Doing so will destroy the device, but you will have the other device that you can keep. Once you have ordered the two units, you select the one to measure by random selection, which is very important. In the scenario that an adversary was able to replace just one of the units, they will likely have replaced both units (and not just one) with imitation or tampered-with units. So testing one of the units will likely apply to tests of the other unit.
 It should be noted that it does appear—from some brief internet research—that so-called "pure water" and/or distilled water are possibly capable of having electronics submerged in them, without any damage to the electronics occurring as a result.

 The 'magnetic weight' of a device can be measured, as in the force of attraction between the device and a magnet of some specific number of newtons force, at a set specific distance away from the device. A simple set of normal (gravitational based) weighing scales can be used for this. What you do is:

 It is suspected that magnetic resonance imaging (MRI) can be used to profile an electronic device, for security purposes. The question is whether the cost of performing such imaging can be sufficiently reduced for use by general users. It is suspected that it probably can. The "50x50mm Small Magnetic Field Viewing Paper" product available here appears like it might help in this regard.

 Like RF imaging/detection , electric field imaging/detection of turned-on electronics might be helpful.

 Straight-forward conventional photography using the visible spectrum can be used to check whether a certain device looks externally (and sometimes also internally) like it should (a form of quality control classed under visual inspection). With respect to both photographing the internals, as well convincing users that there is no embedded, hidden espionage technology, it is useful for the device to use transparent materials wherever possible.

 T rays are analogous to x rays but instead involve infra-red. Infra-red filters appear to be readily available, at relatively low prices, for cameras (including those on mobile phones). T rays are capable of passing through plastic but not through metal; this property enables t rays to be used to detect metal weapons concealed on persons. Could it be possible that such t rays might also pass through silicon? If t rays do in fact pass through silicon and related materials, then perhaps cameras (including those on mobile phones) can be adapted to take t rays of electronic devices, as a form of security verification.

 The "Mylar X-Ray Film, TF-160-255, 500 Pre-Cut CIrcles, Unopened" product priced at just £12.75, appears to be X-ray capturing film at a relatively low price. Since x rays are present in sunlight, could it be possible that an x-ray photograph of a device could be created simply using sunlight and this film, by keeping the apparatus and device still over the course of hours or days (perhaps with the use of a filter that blocks out all non-x-ray light)? It looks like x rays already form an accepted method of confirming certain aspects of at least certain microchip electronics hardware—see here and also information on industrial radiography.

 Microwave testing is already a tool used in engineering for performing non-destructive testing to find defects in technical parts. As it is presently used in engineering, it most likely isn't low-cost enough. However, could it be that a microwave oven, in conjunction with a smartphone, might be capable of being able to perform such testing? The project hosted here could possibly be useful for this.

 From internet research, it hasn’t been possible to find much information about this. However, it seems like it might be something that is useful, especially with respect to any incidental RF fields produced by powered-on electronics.

 Ultrasound images and/or readings, appear to be quite likely useful for security authentication of devices. Unfortunately, normally the price of the associated equipment is relatively high. However, there is such a thing as a DIY ultrasound imaging kit which could directly or indirectly bring down the cost of using this technology. Also, a simple ultrasonic sensor, which seems potentially to be much cheaper and affordable, may be sufficient for exploiting ultrasound to do security authentications. According to Wikipedia, ultrasound testing has been used for industrial non-destructive testing of welded joints from at least the 1960s.

 Other usable non-destructive testing methods might be documented on Wikipedia, especially at the address of this hyperlink. Other such methods may also be documented here on the betrusted wiki.

 Because of things like hidden cameras, you may want to enter security credentials (such as passwords), only in secure locations. For example, you may choose not to unlock your phone when in public places because of the increased likelihood of an adversary surreptitiously photographing or videoing the password you enter.

 The United States of America used to have severe restrictions on the export of cryptographic technology. In contrast, other geographic areas (such as perhaps Germany or the Netherlands) probably are relatively liberal in respect of such technology. With such variations in mind, the level of security you attain may depend on which geographic areas you use for the various elements of your security.
 Also, certain geographies are more prone to attack because of various factors such as things of a political nature, as well as things to do with how powerful the local military are. In this respect, it may even be worthwhile to rely on geographies that are technologically backward, and that have weaker politics and/or political groups.

 Adversaries may initiate their attacks only from a certain time onward. And perhaps we can make assumptions as to when those attacks were definitely not taking place. For sake of example, let’s say that we have an assumption that we were not being attacked six months ago and so were not compromised at that time. If some of the artefacts produced from historic activity dating from before six months ago were isolated six or more months ago, it might be possible to gain extra security drawn from such artefacts.

 Nine months ago, I downloaded the public key for some website, and saved it in a way that kept it quite isolated from other systems from that time onward. For example, isolation may have been induced by printing out the key, and keeping it in a safe. Isolation could also have been induced by burning it to an encrypted read-only CD.
 Now that nine months have passed, I find that adversaries are tampering with my internet communications so that I am downloading the incorrect key. In reliance on 'security based on time passed', I can retrieve the genuine key I saved nine months ago.

 I often engage in email exchanges with a colleague who always writes their public authentication PGP key at the bottom of the emails they send. Three months ago, an adversary started intercepting the emails and changing the key in all emails sent henceforth. By relying on 'security based on time passed', I can access the emails from my colleague from before six months ago (a time at which I know I had system security), and obtain the genuine key. I can then see that the key is now different and therefore figure out that something suspicious is now happening.

 Note that ‘security based on time passed’ can have a vulnerability in respect of security holes in software. For example, software from 5 years ago may have security holes that were discovered and published since then, and from this perspective, it may be better not to rely on that historic version of the software, and instead try to obtain a newer version of the software securely (where the holes have been fixed). With this in mind, if using 'security based on time passed' in conjunction with software, it may be best only to use it with very simple software, where the associated algorithms and code have been thoroughly security researched and tested. This is to mitigate against the chance that security holes are discovered subsequent to your storage of the software under this principle.

 The time taken to forge something, can be used in security mechanisms. For example, someone could place their mobile phone in a seamless ink-absorbing paper bag, the tearing of which is hard to repair through the use of things like super glue, and then sign a random fountain-pen ink squiggle on it. The time taken to forge a replacement paper bag with the same squiggle, can mean that the phone is secured for several hours from the time of the squiggle.

 Instead of entering your security credentials at any old time, a selected window of time can be chosen when security is high based on factors such as when hackers are awake, etc. The security credentials can be entered in that window of time, and they can be entered so that you don't need them again for a while. Eg. log-in to your computer at 6am because most hackers in your own time zone are perhaps asleep at that time.

 Simple measures can be put in place to help remind oneself to stay secure. For example, when using a laptop, why not rest it on its wallet case (if it has one)? That way, you are reminded to place it in its wallet case when you close it up. Another simple measure is not to leave a key in an unlocked self-locking padlock—you no longer need the key, so put it away. That way, you reduce the risk of forgetting to store the key after you've used it.

 The forming of security habits is another simple measure to help prevent forgetting to secure things. On day 1 and day 2, perhaps you make mistakes in your security routine; however, through simple repetition over many days, weeks, months, etc., you simply reduce more and more your mistakes because of the force of habit acquired.

 Building your own devices and security can be good for security reasons. You can better make sure that hidden espionage technology (possibly embedded in materials) is not present when doing it yourself (DIY). The DIY principle can be even more effective when you choose to use very cheap and commonly available materials, because you can often be more sure that hidden embedded espionage technology is not in such materials. For example, why not think about possibly building a computer out of cardboard? You can pick cardboard at random, and be pretty sure no hidden espionage technology is embedded in the cardboard.
 The DIY principle can also be applied to building software, as in you can do things like build software from source as touched upon in the earlier section entitled “Compiling from source”.

 The Heads system outlines a security principle that can perhaps be roughly described as 'destroy-key-when-attacked security'. The trusted platform module (TPM) on a motherboard stores the encryption-decryption (symmetric) key that is only accessible upon entering the correct password. The Heads system will have the TPM destroy the key if incorrect passwords are entered too frequently (if it seems like the computer system is under attack [in relation to so-called rate limiting]). Once the key has been destroyed, the key should no longer be on that computer system. The true user will find out that the key has been destroyed, and then use their backup measures to retrieve the key (relying on the backup of the key outside the computer system). This security principle can be applied more broadly. For example, cryptocurrency (such as Bitcoin) keys can perhaps be safeguarded in the same way.

 Perhaps a novel way to ensure better communication of things like public keys, is for an organisation to create a security token containing the key, that is very expensive to produce and replicate. It could be, for example, a genuine gold coin with the key on it, or some kind of holographic paper or card with the key on it. What would happen, is that the organisation would post out the security token to end users. The end users would then possibly pass the security token amongst themselves, or just post it back to the organisation. Because it would be so expensive to (re-)create the token, the token would not be thrown away, but simply shared in order to communicate the public key to end users. Adversaries would find it too costly to create fake tokens, because of the expense in creating the token.

 Footnotes


text:
End-user Computer Security/Main content/What to do when you discover your computer has been hacked

 = 𓆉 ≅  End-user Computer Security Inexpensive security

=

 If it is ever discovered that a computer has been hacked,

 You may be tempted to change such security credentials straight-away after discovering that you have been hacked. However, could it be better to wait until you are sure that your system is secure rather than changing such credentials using an unsecure system?

 The National Cyber Security Centre for the UK (NCSC) outlines steps to be urgently taken when you’ve discovered you’ve been infected with malware. Also, see here for their guide for small businesses on response and recovery from cyberattacks.


text:
End-user Computer Security/Main content/Miscellaneous notes

 = 𓆉 ≅  End-user Computer Security Inexpensive security

=

 Cyber-security advice is freely available on the National Cyber Security Centre (NCSC) website. Specific NCSC information that may be of interest to you:

 See here for cybersecurity-standards information from which might be obtained, insights into the security measures and processes helpful for an entity’s security.

 Consideration of deep hardware-hacking attacks is probably an overkill for most individuals, sole traders and small businesses—have to draw the line somewhere. However, if you are interested in defending against such attacks, the Novena open-source computing hardware platform and other related information hosted here, may be of interest to you.

 If you are interested in adopting security measures suggested for Bitcoin users, have a look at the Glacier protocol.

 Phones and computers can be turned into motion detector alarms, by using their built-in cameras and other sensors, with apps such as the “Haven: Keep Watch” app. This could provide extra security during sleeping hours. Psychic phenomena, including phenomena that have been verified and accepted by the scientific community, might be able to induce a person to stay asleep or suffer amnesia whilst intruders enter premises and room whilst the person is asleep; technological measures such as loud alarms may be helpful to defend against such attacks.

 White-on-white text in computer documents and emails can be used for hiding and sending security sensitive information. This might be both simple and effective for low threat models.

<BR>


text:
End-user Computer Security/Appendix/New security inventions requiring a non-trivial investment in new technology

 = 𓆉 ≅  End-user Computer Security Inexpensive security

=

 An interesting security idea involves using CPU idle time, and the idle time of other processors, to put the processors to work to perform computations that increase trust in a particular software. The processors would be put to extra work, but not so much extra work so as to have the computer use more electricity (so as not to impact on computer operating costs), to mine so-called “authentication coins” (similar to BitCoins). The so-called “authentication coins” would be mined so as to provide some authentication for some piece of software (perhaps through PGP signing of the installation files of the software), thereby increasing trust in the software. If there are 100,000 users using the particular software, all having each generated these “authentication coins” (which don’t cost anything to make when using idle time in such ways), and those coins are published, a new user can download the published coins, and then say to themselves something similar to the following:  1,000,000 “authentication coins” have been produced authenticating this software;

I’ve just algorithmically checked the coins are genuine, using a trusted installation of some trusted software, and they are indeed genuine;

That's a great deal of processor-hour work;

It's quite unlikely that an adversary has invested this amount of processor work in authenticating any hoax malware-containing software simulating the true software, so I think I can trust this software is the genuine software from the real provider.

 A counter-argument to using this protocol is that adversaries with supercomputers can easily fake such numbers of coins. That appears likely to be true when only one piece of software is made a target.
 To mitigate against this, wide adoption of this protocol can be promoted. If every provider adopted this protocol, the activities of adversaries in general would be reduced, because of the general increase in work required for each hacking activity of this type. This would lead concretely to a higher-than-otherwise increase in security for each user (incidentally, this security principle, that can perhaps be termed as “security via mass adoption”, can also be potentially achieved when publishing security methods ). The knock-on effect is that of increasing security both for the individual user, as well as for everyone in a general way.

 Suppose an organisation publishes a digital public key on a website, and suppose the website address is well known. The website address may be printed on business cards, advertising, in magazines, in TV adverts, etc. such that it is well publicised. However, let's say the public cryptography key isn't so well publicised, and in a connected way, not so well trusted. By using cryptocurrency technology, mining activity can take place at the 'node' represented by both the website address and the public key. The mining can take place during the idle CPU time, and idle time of the other processors, of the organisation’s computers. Over the course of a year, let’s suppose 100 coins are mined. The credentials for those coins are published on the web-page on which the digital public key is also published. Users can then download the key, along with the 'proof of work' embodied in the coin credentials, and see that the public key is buttressed by the mining work conducted to increase trust in the public key. Whilst it's true that adversarial entities can also do mining to buttress fake keys, it does cost them. The “security via mass adoption” principle (mentioned in the last section) applies, so that mass adoption can substantially increase security both for the individual user and for the wider community. Perhaps mandating that such mining take place for organisations, might happen one day, in order that users are better enabled to trust the digital keys of such organisations.
 The same authentication protocol can also be used for the public digital keys used in security certificates.

 Additional security can be added to lock screens, if:

they play music through the computing device’s speaker from a ‘favourites’ music playlist whilst the lock is on,

that music is turned into a high-pitched continuous beep when a person inputs into the device (whether that be by touching a touchscreen, pressing a keyboard key, moving a mouse, or otherwise), and

the speakers stop outputting sound altogether when the lock is unlocked.

 Please refer to the earlier section entitled “Play sound continuously on computing device” for some of the reasons why this improves security.
 Even more security can potentially be attained if you also use 2FA (two-factor authentication ), with the second factor being a hardware security token, to unlock the lock screen such that when people correctly enter your knowledge factor without the token being present, the audio changes to a special alert sound indicating that someone else has just attempted to unlock your device with what is in fact the correct knowledge factor, but actually failed because of the lack of security token.
 The security outlined in this section might be good for users in public spaces that are shared with others, where the user might move around away from their device but still within hearing distance of it.

Server sends to the client, white noise audio that is genuinely unpredictable because of the random element in the noise.

The client hears the audio perhaps out of their headphones as well as out of their laptop speakers.

The speaker/earphone set-up is contrived such that the noise audio is heard coming out just near the microphone (perhaps by placing one of the headphone earphones just by the microphone).

User whispers almost inaudibly, the password into the microphone.

Server receives audio from the client's microphone (the noise originally sent from the server to the client is in the background of such audio [because of the speaker/earphone set-up just mentioned]).

Because the server knows the precise noise audio sent to the client, the server can remove the precise noise from the received audio to authenticate the password.

If an eavesdropper records audio sent by client to server, they cannot replay that audio to achieve authentication (a kind of replay attack), as the whispered password is inextricably admixed with that specific, precise and unpredictable noise (unpredictable partly because that precise noise audio is not sufficiently repeated on other occasions).

Hopefully, the password audio is also not discoverable by an eavesdropper primarily because of the user whispering the password very softly, such that the whispering is completely blotted-out by the noise audio unless you know precisely what noise audio was used—hopefully, standard denoising algorithms that an eavesdropper might try, won’t work, but instead simple subtraction of the precise noise audio (which the server will hopefully be able to do) will work.

 A possible idea is to translate open-source source code to a higher-level programming language (such as perhaps the Eiffel programming language) [perhaps initially in an automated way], in such fashion that the software has fewer potential security compromises. The Eiffel language is apparently good for safety, and so also good for security (in a related way), when compared with the majority of programming languages, so if you want fewer security risks (even if it is at the price of somewhat slower speed execution), then perhaps porting to Eiffel (where possible) could be a good idea depending upon the circumstances. An example of how Eiffel can improve safety: suppose you have a function that implements some kind of complex sorting; Eiffel can add a sanity-test constraint using Eiffel’s specially-designated language constructs for post-conditions, to throw an error if certain output properties are wrong (perhaps something as simple as checking that some chosen element is indeed greater than one of its preceding elements).

 With respect to a USB cryptography-key security token, if the product comes with a pre-loaded private key for authentication, once the product arrives, the user can use the key to sign some long message they’ve just randomly generated. The user will then receive the message digest. The user can then with their secure communications device, submit the long random message to the authentication server of the company that produced the token. The authentication server has the same private key securely stored, and so, is able to reproduce the same message digest. The user sees the server-generated message digest, and then is willing to trust that the product is genuinely the same product produced by the authorised provider, at least in respect of certain key components of the product. This security method (a kind of zero-knowledge authentication protocol) works against 'complete fake' attacks focused on the token, but will not necessarily work against tampering attacks focused on the token.
 If the device is designed so that the private key is destroyed whenever any tampering is attempted, then defence against this latter kind of attack will also be achieved. Trammell Hudson's Heads boot firmware, that destroys a private key within a TPM (Trusted Platform Module) when incorrect passwords are entered too frequently (see the section entitled `“Destroy key when attacked”`), coupled with the use of epoxy resin to protect hardware components from tampering, might be helpful in the drawing-up of such design features.

 Footnotes


text:
Template://

||


text: Template:Entrepreneurial learning/Source


text: Template:Sane

title: Template:Sane


text:
Template:Sane/doc

Usage
at the point in the markup where a known value is needed.

The output is

title: Template:Sane/doc


text: Template:Bu

title: Template:Bu


text:
Talk:End-user Computer Security/Main content/Broad security principles

Adapt business/work model to lessen impact of threats in threat model
A new broad principle that can be added to this section, might be the adapting of an entity's business/work model to lessen the impact of threats in the entity's threat model. For example, in circumstances where intellectual property theft is rife, you could change your business model so that you are not so dependent on intellectual property protection. This happens in the open-source community, where the business model is not so reliant on protecting intellectual property; instead, revenues are generated in ways probably mostly immune to attacks based on stealing intellectual property.

--MarkJFernandes (discuss • contribs) 13:56, 17 April 2020 (UTC)

Mistakes in "Security measure of taking key out of self-locking padlock" photos
Mistakes were made in the taking of these photographs. The padlock should appear to be unlocked, and also ideally, probably the box should be opened (rather than closed).

MarkJFernandes (discuss • contribs) 14:11, 21 May 2020 (UTC)

Relationship between “Destroy key when attacked” principle and military strategies
I've read through the list of military strategy and concepts at https://en.wikipedia.org/wiki/List_of_military_strategies_and_concepts, and also done some brief internet research, but can't find this principle distinguished anywhere. It is similar to 'scorched earth' policies but not quite the same because there's no retreating or advancing.

MarkJFernandes (discuss • contribs) 14:13, 21 May 2020 (UTC)

Add "Ward off criminals by being public about your security" as a broad security principle?
Criminals can be warded off when they believe you have good security in place, especially when they believe they might be caught by the police because of your security. Should this be added to this chapter as a broad security principle? Maybe it's not broad enough and should be instead put in the "Miscellaneous notes" chapter. Or otherwise maybe it just isn't significant enough to be in the book at all.

It is quite related to the "Publishing security methods" broad principle, and perhaps should be mentioned in the documentation of that principle.

"Security by screaming" as broad security principle?
Perhaps there is a broad security principle that can be labelled as "security by screaming". Essentially, more security is attained by proclaiming to the world, almost in a screaming-like way, about the awfulness of your security compromises. In such fashion, attackers may be warded off from fear of being found out, possibly because of increased attention paid in their direction.

== Add "Security through obscurity" reference to §"Publishing security methods" ==

"Security through obscurity" contrasts the "Publishing security methods" broad security principle. The Wikipedia page for "Security through obscurity" gives justification for why publishing security methods is likely better.

Add "Security layers with differing credentials, for improved security of more valued assets" as broad security principle?
Adding this was an idea borne out of initial discussion of this book with the Qubes user "Catacombs".

Their idea was possibly to include information on "..nested encrypted folders...". They said that the idea was something like that after the hard drive's full-disk encryption, there would be a second layer of encryption for all of their highly-private letters by using an encrypted-folder mechanism (distinct from the full-disk encryption). The idea would be that a user would enter their credentials initially to get access to the operating system which would decrypt the full-disk encryption, but would not decrypt the encrypted folder. In order to get access to the encrypted folder, the user would have to enter a second set of credentials (perhaps a second password). In such ways, would there be something like access control to a building and then greater access control to a highly confidential room in that building. It was put forward by Catacombs that leaving "...information openly in the file structure..." was not safe. They further implied that such a security mechanism overcame such security weakness connected to not having strong security for information more sensitive than the average information on your system.

Catacombs said that in 2009, they had a MacBook Pro which had the ability to create a software-driven encrypted partition inside of the main file structure. They further added that reviewers felt the encryption used back then was quite good.

I suggested that a more general concept of "encrypted container within encrypted container" might be appropriately added to the book. I went further and said that perhaps an even more general concept of "encryption within encryption" should instead be added. Upon reflection of this latter general concept of "encryption within encryption", I realised that an even more general concept existed that included the physical security mentioned by way of analogy in the building-and-room analogy above. I've labelled this concept as "security layers with differing credentials, for improved security of more valued assets" because I could not find it singly labelled elsewhere. The concept is perhaps related to User Account Control (UAC) which is actually touched upon earlier in this book, in the "Regarding operating system" section, in the following excerpt:

 "Some general security advice in relation to using an operating system, is for users to have an administrator account that is different to the standard account users use for everyday computing. The standard account has fewer privileges. The more powerful administrator account, that also has higher associated security risks, should also have a “minimised” exposure to risk due to it being used only when needed—when not needed, the less risky standard account is instead used."

It is also related to the concepts of security clearance and multi-level security but is not the same as either of these concepts.

== Considered whether high-latency email should be mentioned in the "Time based" broad-security-principles section, or elsewhere in book... ==

Decided such a concept likely should not be mentioned in book. The concept appears to be more about having anonymity, and the book doesn't deal so much with establishing anonymity. Knowing how to be anonymous in computing doesn't appear to be that useful to everyday computing conducted by most users. It is perhaps more useful to certain fringe activities, such as the reporting of human rights abuses. Also, such things are very likely well documented elsewhere on the net, probably even being available as free resources.

== Add information under "Geospatial" broad security principles, concerning potential security advantages gained by moving around? ==

Security advantages may be gained by moving around, and computing from different geospatial locations, especially if an adversary is focusing their attacks on a specific geospatial location. Such a strategy is probably documented as some kind of military strategy. The Qubes user "Catacombs" has said that such an approach might be useful for a country like China, presumably because of the totalitarian government there.

Improvements to §"Time based"
The subsection "Based on time taken to forge" should probably be placed under the section "Based on time passed" since it too is based on time passed: security is attained based on how much time has passed, on how much time has not passed perhaps. In a related way, the current content under "Based on time passed", might be best placed under a subsection of that subsection, called something like "Security derived from age". Another subsection could be created under the "Based on time passed" subsection called something like 'based on security credential expiry date'. For example, you may wish to use a private key to create new mobile phone lock passwords that expire at the end of each day (perhaps simply by PGP signing the day's date). If an adversary were to capture the password, perhaps due to your unlocking your phone in a public shopping centre, then because the password would expire at the end of the day, it might mean you still maintain a good level of security.

X-ray and T-ray probably should always have the initial letter capitalised....
X-ray and T-ray probably should always have the initial letter capitalised. If this is the case, correct the mistakes where this has not happened not only in this chapter, but in any other places in the book.

== Rename §⟪Relying on high production cost of certain security tokens⟫ → ⟪Using high-cost-to-forge barriers for greater security⟫? ==

Such generalisation in this "Broad security principles" chapter is generally desirable because the chapter is focused on broad/general principles. It does appear likely that the proposed new name constitutes a distinct and genuine broad security principle.

If such renaming took place, the previous body would perhaps then be again placed under the ⟪Relying on high production cost of certain security tokens⟫ heading but the heading would instead be a sub-heading under the suggested and more general heading of ⟪Using high-cost-to-forge barriers for greater security⟫. Also with such renaming, the "Cryptocurrency-like mining to increase trust" inventions could then be appropriately linked-to as being categorised under the new heading.

Cheap SD cards are a security risk partly because of how cheap they are. An adversary perhaps can replace 1000 cheap SD cards with deceptive espionage-tech-laden fakes without too much difficulty because of their low cost. The same could also be true with BIOS EEPROM chips. However, replacing 1000 expensive SD cards, where the greater expense can be verified using vigorous checks on the higher capacity and/or speed of the SD cards, is probably much more difficult. For both SD cards and EEPROM chips, such greater expense perhaps could also be established by filling each one with a blockchain signing the chip's serial number or some other suitable identifier. The ideas of this paragraph could perhaps be placed under another sub-heading of ⟪Security by costly verifiable features in device⟫. Interestingly, gold-plating EEPROM chips and the like, could perhaps provide such greater security. There would have to be some way for users to authenticate that the gold were genuine, and there appears to be much information on the internet regarding testing the authenticity of gold—see https://www.wikihow.com/Tell-if-Gold-Is-Real.

This idea of there sometimes being more security due to the higher costs associated with forging, might lead one to believe that the CPU in a computer system is less of a point of attack than the embedded controller in the same system: it's probably generally cheaper to create a fake EC processor than to create a fake CPU. Following a similar line of thought, system-on-a-chip systems (SoCs) may provide a security advantage over other systems having greater numbers of individual components able to be, after manufacture, physically separated and replaced: if you want to put a backdoor in the CPU (for example), you still have to go to the expense of replicating the rest of the SoC's functionality for SoC-based systems; on the other hand, if you are not targeting an SoC-based system, you can just create a fake CPU which would likely be cheaper than making a whole fake SoC.

Perhaps mention 3D printers, and FPGAs programmed as CPUs, in §⟪DIY security principle⟫?
3D printing would seem at times to be an application of the DIY security principle. By 3D printing hardware and other physical objects, you can probably be more confident regarding the integrity of the printed items (especially in respect of there being no hidden espionage tech or other hidden "maltech").

On another note, more related to microchips, FPGAs can be programmed to function as CPUs, in a DIY way, such that certain CPU attacks (such as via hardware backdoors) can be thwarted (see "Verifiable CPU" section at https://www.bunniestudios.com/blog/?p=5706).

These thoughts can perhaps be mentioned in the §⟪DIY security principle⟫. However, because the ideas are quite concrete, perhaps they should be placed elsewhere in the book, either in addition or instead.

How to compare live OS discs obtained using multiple channels, when you have no trusted OS....
In respect of §⟪Using multiple channels to obtain product⟫, a scenario may arise where you have what should be multiple copies of a live OS disc, obtained using multiple channels, but no trusted OS that can be run to do byte-for-byte comparisons of the discs to make sure they are all the same. In such a situation, you can do some form of checking by loading each disc in turn, and then within the OS session loaded for each of the discs, byte-for-byte comparing all the other discs to the particular disc loaded. In such a scenario, none of the OS discs are trusted, but the chances that all of the discs have been compromised, is quite low, and you can leverage such probability, to reach some level of confidence that none of the discs have been compromised, if such be the case, whenever all the just-mentioned byte-for-byte comparisons throw-up no differences (pass successfully).

This principle was developed for a Raspberry Pi project attempting to establish a secure computing environment for business purposes—see here for more about the project.

Is there a broad security principle based on having a cheap set-up?
There may be a broad security principle based on having a cheap set-up. Such extra security was touched upon in a Raspberry Pi project attempting to establish a secure computing environment for business purposes—see here for more about the project. Essentially, the security advantage I am discerning (that I think probably constitutes a broad security principle), is that if there is ever sufficient reason to believe that such a cheap set-up has become compromised, the user is then able to purchase a brand new non-compromised set-up at a low cost, with the possibility of selling on the old set-up as either spare parts, or advertised as a potentially-compromised system. You could perhaps do the same with an expensive set-up, but the risk of not being able to find buyers for the old system, together with the greater absolute loss incurred when more expensive goods become second-hand, could mean that the financial risk of catering for such contingency is simply too much to bear.

Do avoiding "bells and whistles", trying to be "barebones", and reducing power & capability, constitute a broad security principle?
Such is touched upon in a Raspberry Pi project attempting to establish a secure computing environment for business purposes—see here for more about the project. It is also touched upon in the geospatial broad security principle, when it is mentioned that a user may want to reduce their power and capability by not unlocking their phone in public places. It is also touched upon in other areas of the book (such as in the "Software based" chapter in the consideration of whether the Raspberry Pi Zero device could be used as a secure downloader).

Having "bells and whistles" simply increases security concerns, and when having high security is important, doing away with them when possible is likely a good idea. By moving in this direction, you may end-up with a system that is fairly bare-bones like perhaps some of the Raspberry Pi products, some of the products conforming to the 96Boards specifications, and some very basic non-smart mobile phones (that perhaps are better to use for secure downloading).

Reducing power and capability, seems to be something of a parallel concept to trying to be "barebones". Essentially, security is leveraged at the cost of reducing power and capability. Why leave certain computer ports exposed when you don't really need them? Perhaps disable them for increased security, at the expense of reducing your power and capability.

Add new broad security principle of "Using an intrusion-detection-and-recovery-from-intrusion approach instead of just a tamper-prevention approach"?
Whilst in an ideal world, preventing tampering absolutely might be desirable, realistically, a security approach of intrusion detection coupled with recovery after the detection of such intrusion, might be better. To prevent absolutely all forms of tampering might simply be too costly. Also, it might not have that much of an impact when the probability of tampering is very low. In such regard, it might be easier, and more beneficial, simply to detect intrusion, and then when intrusion is detected, to re-establish your system(s) so as to "eject" out any possible tampering from your system(s).

When using an intrusion-detection-and-recovery-from-intrusion approach, you may want to use cheap components, so that if intrusion is detected, it is not too costly to replace the components with new components that you know have not been compromised (see the "Is there a broad security principle based on having a cheap set-up?" note for more about this).

In respect of trying to lock down the code and data associated with OS installations, bootloaders, BIOSes/UEFIs, and data files, it may be much easier simply to detect intrusion where tampering may have possibly occurred, and then just to reinstall all the data and code from secure backups after such event. This approach is perhaps similar to instead of trying to establish that an OEM installation has no malware in it, simply reinstalling the whole of the OEM setup so as to have certainty over the security of the computer system. The "Digital-storage security through multiple copies of data" note is relevant to such an approach.

Add §⟪Size based⟫?
There appears to be broad security principles around the subject of size. In such a new section, there could be a subsection called something like "bigger things are harder to steal", and a subsection called something like "smaller things are easier to hide". These ideas appear to constitute broad security principles.

By following the principle concerning bigger things, you may choose (for example) to use a big tower desktop computer instead of a small laptop/netbook, because it is easier to spot someone stealing such a big computer than it is for a small laptop/netbook (can't put it "under your jumper" and walk out). Such a big computer may also be cheaper and easier to use when in just one location, which could constitute other reasons to go for such a computer.

By following the principle concerning smaller things, you may choose to store a large amount of data on an SD card that you hide in the lining in your jacket when you are travelling, rather than on a big external HDD/SSD drive. In such instances, greater security might be attained by using a smaller storage medium rather than a bigger storage medium (in contrast to the other size-based principle just mentioned).

These principles are briefly touched upon in the §⟪Physically removing storage component(s) from the rest of the computer system, and then securely storing those components separately⟫. The principles do not necessarily need to apply to physical size. They could, for example, apply to disk-space size; a key file may be easier to hide in email attachments using steganography if it is quite small; in contrast, it may be harder for an adversary to steal a key file through data transfer methods, if the file is extremely large.

Bigger things can be more costly to maintain and an easier means by which adversaries can launch "trojan horse" attacks. In respect of disk space utilisation, one thing perhaps to consider is the malware risks for software taking-up large amounts of disk space: malware checking takes longer, and there is a greater risk of failing to spot malware because of the greater complexity associated with larger space utilisation. Such size limitation as a security principle, is touched upon in the "Dealing with the situation where you want to work with potentially security-compromised equipment/software" note as well as in the security invention mentioned in the "Design feature for enabling the detection of malware in BIOS firmware" note on the talk page of the "New security inventions requiring a non-trivial investment in new technology" chapter.

Add §⟪Having thorough, great, and easy customisation in the building and maintenance of systems⟫?
Custom-building PC/system where in its building, as well as afterwards, great and difficult-to-predict customisation is possible, where components can be easily replaced using commonly-available components, appears to be a good idea.

Great customisation can mean that extra security mechanisms can more easily be implemented, such as replacing an opaque computer case with transparent materials for easier visual-inspection security authentications.

Easy customisation in the maintenance of systems, can mean that if it is suspected that a particular part may have been compromised, it alone can be easily and faithfully replaced cheaply—the whole system need not be "trashed", only the part to be replaced.

Thorough and great customisation can mean that adversaries cannot much predict beforehand what system the user will have. With prediction, the attacks of adversaries can be more focused, and can exploit the re-usability of attacks formulated previously; without it, adversaries may be at a loss as to what attacks will work even after finding out the system configuration, due to any pre-formulated "canned" attacks failing as a result of the system having been highly customised away from being vulnerable to such "canned" attacks.

Not 100% sure these ideas constitute a broad security principle.

== Concerning §⟪User randomly selecting unit from off physical shelves⟫,        and add §⟪Anonymity based⟫? ==

After trying to put into practice the "User randomly selecting unit from off physical shelves" broad security principle in respect of securely acquiring a smartphone (as advocated presently in the advice given under the §⟪Getting an uncompromised smartphone and obtaining software with it⟫ of the "Software based" chapter), I have run into a few snags. Unfortunately, it appears most physical shops in the south east of England (UK), do not have smartphones actually on shelves where a user can personally pick units themselves with their own hands. Some stores (including the Carphone Warehouse as now currently merged with PC World), will have staff go and get the unit for the model that you pick-out in the front of the store. Unfortunately, this is open to attack by store staff, and completely undermines the security advantage highlighted in the principle. The lack of ability to buy mobile devices by making use of this principle, coupled with the research discovered in the writing of this book, makes me strongly suspicious that such inability to make use of this broad security principle, is a way to leave open the possibility of hacking phones targeted at certain individuals and groups. I was hoping PC World, being a big physical store, would lend well to this security principle, but alas this does not seem to be the case. This notwithstanding, the broad security principle might still be able to be used at certain wholesaler warehouse-type stores such as Costco; however, from photos of the inside of Costco stores, it does appear that probably they too do not keep actual phone units in the main customer area. Being in the midst of this COVID-19 crisis, and with the renewed and even frantic push to switch to online retail, it might be that this broad security principle will not be so good for securely acquiring phones from this time onwards, at least in the south east of England.

Not all hope is lost though, in regard to real physical in-person shopping. Amazon is innovating a new kind of store known as Amazon GO, which is advertised as being a cashier-less kind of store. It is scheduled soon to arrive in the UK, and its aspect of not having cashiers, may mean this broad security principle of random selection might become effective. The hurdles involved in hacking the technology, will likely make hacking it non-existent for the case of targeting individuals with "dodgy" phones.

There is probably a broad security principle that lies in being anonymous. When a person does things with anonymity, it can be harder, at times even impossible, to individually target the person, and this can result in greater security. In any case, somehow the following ideas should be added to the book, whether in a new section for such a broad security principle, or otherwise. The ideas have a strong effect on the advice given in the §⟪Getting an uncompromised smartphone and obtaining software with it⟫ of the "Software based" chapter.

Using the Amazon Hub Locker service in conjunction with Amazon-fulfilled orders, is probably secure if you do not include any identifying details on the delivery address (such as your name). At the fulfilment centre, the Amazon processes are likely to be secure such that staff have no awareness of what order is going to which customer. If delivering to Amazon Hub locker, in manner just mentioned, the delivery staff/driver, will quite likely not know for whom the parcel is. After delivery, the security at the Amazon Hub locker (which uses a digital unlocking pass code sent to the buyer, as well as the aspect of there being several lockers at each site into which the delivery might be delivered [making it harder for individuals to figure out which locker needs to be broken-into for the purpose of targeting you]) will likely be secure enough to prevent people from getting to your locked item. When you receive the email saying that your delivery has arrived, you should not look at the email until you have arrived at the locker. When you arrive, you then look at the email and get the unlock code and locker number (if on the other hand you look at the email quite a while before arriving, someone may be able to intercept the code and locker number whether by means of clandestine photography or psychic interception). The email delivery should be secure enough if you use a mail server that insists on encrypting the transit of emails whenever the mail server on the other end is set-up for such capability (GMAIL servers are examples of such servers), and if also the Amazon mail server has the same behaviour (I would be very surprised if the Amazon mail servers didn't automatically use the standard mail-server-communication encryption, for emails sent to mail servers able to communicate using such encryption technology.)

It is likely important that a big business such as Amazon is used, partly because small businesses don't necessarily have as developed security practices and measures. For example, if you shop on the website of a small business, they might spy on your IP address, and in some cases, use that to target you. Such is probably unlikely with a big business like Amazon because of the likely many technological and organisational barriers to such activity. You could possibly overcome IP-address-based targeting, by using anonymity-oriented practices such as using a short-lived dynamic IP address (for some set-ups, if you just restart your broadband router, you'll get a new IP address), or a VPN.

On the internet, it is advised that greater anonymity can be leveraged by paying for Amazon purchases with Amazon gift cards rather than with a bank card registered to your address and person. Not sure whether such is necessary, but it could help—using gift cards does seem like a useful idea for generally remaining anonymous across all types of shopping (not just in respect of Amazon shopping).

Interestingly, I looked into whether buying from a third-party seller on Amazon might be secure enough for my purposes, simply because I wanted to save money, and it turns out that buying from a third-party seller might be even more secure—it is certainly a potential way to save money when trying to acquire goods securely through Amazon. Presently, you still need to make sure that the order is Amazon-fulfilled, as otherwise you are not able to use the Amazon Hub Locker service; such use is required for attaining the needed anonymity. Amazon customer support on 23rd November 2020, said that only the name and delivery address would be passed on to a third-party seller when buying from such a seller through Amazon, and that in particular the email address, phone number(s), bank card details, and billing address would not be passed on to the seller. When using the Amazon Hub Locker system, you should (as articulated above) make sure the delivery address doesn't include your name. In addition to this, when buying from a third-party seller, you should also make sure the name data (outside your delivery-address data) doesn't give indication of your true identity, since the name data might be passed onto the third-party seller and that third-party seller might not be trustworthy (they will quite likely not be as trustworthy as Amazon). Brief internet research, as well as my prior experiences, seem to indicate that it is likely legal in the UK to use a pseudonymous alias in purchases. To effect such use for such purchases, you will need to change the name data both in the delivery address and your name fields to some alias name that doesn't much identify you, and that also doesn't arouse any suspicions—using a name that might be commonly found in the society in which you live, but that isn't too obvious (perhaps avoid names like Joe Bloggs or John Doe?) might be a good idea. Fortunately, from my analysis of the "Amazon Conditions of Use and Sale" terms dated 29.1.2020, that version of their contract allows for the use of pseudonymous aliases. I can imagine that many Amazon customers want to buy anonymously, and that Amazon has baked this facility into their shopping experience. It's easy to change your name data by simply going into the Amazon account settings for your account, and making the appropriate changes. By following the measures outlined in this paragraph, the third-party seller should hopefully be oblivious about who the purchaser is behind each such order, and so will hopefully not be able to target you on an individual basis (nor pass your details to others for any such targeting). You should then have enough security to buy digital electronics goods such as computers and smartphones, securely.

It should be noted that the Amazon Locker Hub service, appears to have Amazon lockers all over the place where I am in Essex, England, UK. Such widespread proliferation, can increase security. You can, for example, keep on changing the destination locker for each new order you make. You can potentially also choose a locker quite distant from you if you suspect you are being targeted based on local geography.

UPDATE. After applying the principles outlined here regarding making anonymous purchases using the Amazon Locker Hub service to set-up a trusted, low-cost, secure, basic, barebones "Raspberry Pi Zero"-powered system (over the 2020-21 winter), I have reached the conclusion that it is likely that somehow the security of the Amazon Locker Hub service was compromised in my purchases. In particular, keyboard remote control seems to have somehow been achieved. Not sure which component was compromised to achieve such remote control, but if one component was compromised, then any of the other components also could have been compromised in the same or similar ways. Because I was very careful to secure physically the system components when they were in my possession (especially at my premises), I am led to believe that the Hub Locker service was compromised somehow. Keyboard remote control seems to be a particular kind of attack that at least I have experienced often across various computing devices. No idea what is the right next step to take now, as to some extent I appear to have exhausted all avenues. Fortunately, because I baked into the 'protocol' the keeping of financial costs as low as possible, in terms of capital expenditure, I have not lost much in terms of money spent—the Pi Zero device is about as cheap a general-purpose brand-new computing device you can get.

== Add information under "Geospatial" broad security principles, concerning "...foreign products may also be more immune to local attacks, such as local attacks from various government agencies..." and related ideas? ==

See https://www.raspberrypi.org/forums/viewtopic.php?f=41&t=286049&p=1731799#p1736148

Add information to this chapter on connections between component popularity and "trustability", and design-modification difficulty and "trustability"?
"...Yes, but then the more generic and popular a component is, the greater the review by users is perhaps? Hardware doesn't change often, and many ppl use certain popular CPUs, perhaps leading to some level of trust ("if you haven't heard of any problems with it yet, it's probably okay")? ..." - https://www.raspberrypi.org/forums/viewtopic.php?f=41&t=286049&start=50#p1737381

Substantiation for "Minimally-above-average security" broad security principle
https://security.stackexchange.com/a/2956/247109


text:
Talk:End-user Computer Security/Preliminaries

Free software & other free computer resources
Since emphasis is made on inexpensive security in this book, should there be a section or other information, dedicated to free software, and other free or low-cost computing resources?

--MarkJFernandes (discuss • contribs) 11:52, 16 April 2020 (UTC)

Add a section called "Computer-driven event logging"?
Logs can be used to uncover hacking attempts whether they were successful or not, and can point a user in the right direction for where extra security may be needed in their systems.

Trammell Hudson briefly deals with whether computers should be completely shutdown, or suspended, in relation to security (see https://trmm.net/Heads_FAQ#suspend_vs_shutdown.3F). This comparison can be extended to whether computers should be powered-on, or powered-off, in relation to security. It may well be better for a computer to be powered-on as in such a state, it can be more difficult to carry out certain classes of attack. In conjunction with a computer being powered-on, computer-driven event logging can be activated, to provide even more security.

--MarkJFernandes (discuss • contribs) 13:54, 16 April 2020 (UTC)

Change section title "Psychic spying of password" → "Spying by mind-reading"?
Perhaps it would be a good idea to broaden the scope of this section by renaming it so that it is for the broader topic of mind-reading. MarkJFernandes (discuss • contribs) 17:31, 8 May 2020 (UTC)

Add section entitled "File-based security" somewhere?
Such a section would deal with the issues of malware in files, digital signing of files, secure communication of files, the backup of files, and probably a few other "file-based security" related issues. Section could be placed in the "Chapter  10:	Miscellaneous notes" chapter, but then again, it might be better to turn this section into a chapter in its own right. Doesn't seem appropriate to place the section in any of the other chapters. MarkJFernandes (discuss • contribs) 09:13, 16 May 2020 (UTC)

Index not complete as of 3rd June 2020
Realised that index would take quite a long time to complete, so decided to leave it in an unfinished state on the book page of this talk page (the Preliminaries page). Might ask for crowd-funding to fund its completion.

PS/2 keyboards are more secure than USB keyboards
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. This has already been mentioned in passing in the §"Pros vs Cons" under the section dealing with whether Raspberry Pi Zero devices should be used as secure downloaders. But it should probably also be documented as standalone info in the book, perhaps in the "Miscellaneous notes" chapter.

Sources of computer-security information that perhaps provide further content for book, whether through direct inclusion or by indirect hyperlinking
The following sources were suggested by the Qubes-user "Catacombs":
 * https://riseup.net/en/security
 * https://www.schneier.com

Dealing with the situation where you want to work with potentially security-compromised equipment/software
Dealing with such situations is related to the "What to do when you discover your computer has been hacked" chapter.

Dealing with such situations is related to the note linked-to here entitled 'additions for "Sandboxing and cloud computing" section'. With that note in mind, old second-hand potentially-compromised smartphones and cameras might be able to be used simply for the purpose of capturing photos in order to send them to an on-site local printer for printing. Once printing completes, visual inspection of the print-outs might then be able to identify adequately whether the print-outs were sufficiently correct (you could perhaps compare print-outs to what was photographed, simply using your own vision, in order to ascertain accuracy), thus perhaps overcoming the potential security weaknesses of such potentially compromised technology.

Sand-boxing and cloud computing also work to contain the ill-effects of malware (possibly hidden within software), so that your other system components don't get damaged. This is touched upon in the §⟪Sandboxing and cloud computing⟫.

Personally, I am contemplating whether it might be possible to use the potentially compromised BIOS/UEFI firmware of my laptop. The COVID-19 situation doesn't help such potentially compromised circumstances.

I have wondered whether my laptop without Wi-Fi and Bluetooth capabilities, as a consequence of removing the Wi-Fi+Bluetooth card, is perhaps fairly secure so long as it is not networked, not connected to other computers/devices, and doesn't have malware on any of its disks or other connected media, even if there should be malware and/or backdoors in the firmware (including the BIOS/UEFI firmware) and/or the hardware. Such malware and/or backdoors, are perhaps not capable of facilitating the deceptive altering of natural-language texts without the aid of outside interventions (interventions such as those through wireless communication), because of the byte-size limitations of such security compromises. The amount of code you can fit in the BIOS/UEFI firmware is limited; such limitation seems to be a security principle for reducing malware potential (it might be worth documenting such principle elsewhere in the book, perhaps in the Digital Storage chapter). Such limitation is exploited in the security invention mentioned in the "Design feature for enabling the detection of malware in BIOS firmware" on the talk page of the "New security inventions requiring a non-trivial investment in new technology" chapter. However, it may still be possible for such malware in the firmware, to insert random snippets of back-door code in executable files. In light of such, if transferring executable files off the computer (such as perhaps as the result of a software-development project), it might be a good idea to run antivirus scans on such executable files. I suppose it could even be possible for such malware to insert random snippets of back-door code into source code. In such regard, it may be a good idea to run some checks on the code as present on a safe and trusted computer, after the code is copied to such computer. If such code then needs to be compiled, the user wouldn't compile it on the main computer, but somehow the copied-over code that had been checked (not the code on the main computer which could still be compromised due to malware) would be compiled on a safe system; cloud computing could perhaps be used.

In the situation where your main computing device may be compromised to some extent, getting your internet connection through an intermediate device acting as a kind of security buffer (like a canal lock or decompression chamber), might be a good idea. Such is dealt with at least in part, in the note linked-to here entitled 'Having intermediate device for internet connection might be more secure?'.

Cryptography can be leveraged to enable the safe use of potentially unsafe devices. Essentially, what happens is that the unsafe device only ever works on encrypted data, and is unable to decrypt that data. Such leveraging is perhaps used in the OS-level encryption of external SD cards in smartphones. SD cards in general are particularly worrying from a security perspective for a variety of reasons. However, if malware and/or malevolent hardware is contained on a compromised SD card, it likely can still be used safely if: i) it is only used for storing encrypted data; ii) it is impossible for any "maltech" on it to be able to get the decryption keys or the decrypted data; iii) and the keys aren't otherwise compromised. This can perhaps be partly implemented by only decrypting data on the SD card in the following way: 1) use a Nitrokey product for cryptographic services; 2) copy encrypted data off the SD card to RAM; 3) physically disconnect the SD card before finally decrypting the copy of the encrypted data, that is stored in the RAM. When reconnecting the SD card, there shouldn't be any decrypted data accessible by any "maltech" in the SD card. It should be noted that historically encrypted data can be hidden on SD cards, so if old cryptography keys become compromised, this could pose a risk to flash memory dating from when the old keys were in use, even if you elected to deep low-level format such media. Please consult the "Digital Storage" chapter for more about the risks of using SD cards.


text:
Wikibooks:Collections/how

to be an entrepreneur

 * Getting Started as an Entrepreneur
 * Getting Started as an Entrepreneur/Opportunity/Defining the Opportunity
 * Getting Started as an Entrepreneur/Opportunity/Entrepreneurship Is
 * Getting Started as an Entrepreneur/Opportunity/Social Entrepreneurship
 * Getting Started as an Entrepreneur/Opportunity/The Idea Factory

 * new enter

title: Wikibooks:Collections/how


text:
Cookbook:Kubaneh (Yemenite Pull-Apart Bread)

Kubaneh (Arabic: كبانة ; Hebrew: כֻּבַּאנֶה), is a leavened bread baked in a greased pot with a tightly-sealed lid, where it cooks in its own vapors. Traditionally eaten by the Jews of Yemen on Sabbath days and holidays, the pot is usually placed in an oven (formerly a clay oven where it was laid upon dying embers or coals) shortly before nightfall where it remains until the following day, when it is eaten for the Sabbath meal or at brunch.

Ingredients

 * 1 tsp salt
 * 2½–3 cups lukewarm water (or enough for kneading dough)
 * 1 tsp dried yeast
 * 3 tsp white granulated sugar
 * 3 cups white, all-purpose wheat flour (optional: try using some sorghum flour)
 * 2 tbsp vegetable oil or other fat
 * 1 tsp black cumin (Nigella sativa; optional)

Procedure

 * 1) Dissolve salt in lukewarm water.
 * 2) Sprinkle yeast over lukewarm water and add sugar. Leave for 10 minutes until yeast is foamy.
 * 3) Add yeast mixture to flour, and knead to form a dough.
 * 4) After kneading the dough, allow it to sit 10 minutes until it begins to rise.
 * 5) Repeat process: turn it and knead it again and let sit 10 minutes until it rises. Repeat this process 3 or 4 times until dough rises to the top of the kneading bowl and one is left with a uniform texture and consistency.
 * 6) Grease the baking pot with the vegetable oil.
 * 7) Divide dough into smaller pieces (8–10 round pieces).
 * 8) Place all dough pieces in pot, one after the other; compacted together. Fill to one-third the capacity of baking pot and cover tightly with lid.
 * 9) Preheat oven to 225–280°F (107–138°C). Bake bread for 1 hour at the higher temperature or 3 hours at the lower temperature. It should be golden brown.
 * 10) Turn bread out onto a plate, turn bread upside down, and restore to baking pot.
 * 11) Cover pot with lid and bake another hour; or reduce oven temperature to 200 F and bake overnight. If desired, remove from oven and afterwards return it only close to the Sabbath.
 * 12) Serve hot with clarified butter, usually also with tomato salsa mixed with chopped coriander.

Notes, tips, and variations

 * During the winter months, some had a custom to add to the baking pot along with the Kubaneh a piece of the fatty-tail of sheep, in which case the bread became a meat-dish. When the bread was eaten as a dairy dish, they would pour butter over the dough portions before inserting the pot in the oven.


text:
Template:RC/doc/use-count/doc

7,000+ Please note that RC is rarely used directly; it’s embedded by MediaWiki:category-article-count on pages of all categories that contain at least one article (i.e. have at least one member which is not a subcategory or a file). Use the following query in Quarry to get the exact count of such categories:

title: Template:RC/doc/use-count/doc


text:
Template:RC/doc

Usage
{	"description": "Displays the recent changes filtered for a category.", "params": { "category": { "aliases": [ "1"			],			"label": "category", "description": "The category to show recent changes for, without namespace prefix; by default the current page’s title", "example": "Book:Lua Programming", "type": "wiki-page-name" }	} }

Example
RC into : gives:

title: Template:RC/doc


text:
Wikijunior:Insect Alphabet/E

E is for Earwig

title: Wikijunior:Insect Alphabet/E


text:
English-Hanzi/White rice is the rice that the husk, bran, and germ is removed

White rice is the rice that the husk, bran, and germ is removed. This changes the flavor, texture and appearance of the rice and helps prevent spoilage and extend its storage life.

白米是去除了外壳，麸皮和胚芽的大米. 这可以改变大米的味道，质地和外观，并有助于防止变质并延长其存储寿命.


text:
History of Flight/Unmotorised

A kite or glider is a motorless aircraft that flies without using engine energy. In fact, because this bird does not have engine power; It should use a negative head angle to overcome the push force and maintain a constant speed. In other words, it takes help from its weight component to overcome friction. The wings of this aircraft are longer and narrower than a normal plane, which give more lift. The kite is mostly flown with the help of a tow plane. When the engineless plane gets high enough, they drop it. By using the force of the wind, the kite stays in the air and slowly decreases its height. If the wind speed is the same as the speed or height of the kite, the kite will be at a constant height, and when the speed increases, its height will increase. Their landing gear consists of a wheel that is placed under the cockpit and behind the tail is another small wheel, which prevents damage to the tail when it is on the ground.

title: History of Flight/Unmotorised