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

End-user Computer Security Inexpensive security
| $^{for}$ | ⦾ individuals ⦾ sole traders ⦾ small businesses |
* Cryptocurrency-like mining to increase trust
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 , 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” $^{(whichdon’tcostanythingtomakewhenusingidletimeinsuchways)}$, 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.
* Port source code to higher-level programming language as a computer-security step having its basis in secure coding
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
| Contents, Index, Foreword | Appendix: Part 2 Example set-ups & implementations |