Secure computing using Raspberry Pi for business purposes

[MarkJFernandes]

Hello all,

I have perhaps a somewhat unusual Raspberry Pi project in mind.

Essentially, I want to establish a secure computing system, especially for business purposes. I've been researching the topic ever since my computer was hacked, and the end result was mostly the creation of a Wikibooks book called End-user Computer Security.

Anyway, I am now looking at replacing my present system with a brand new one but am unsure which way to go. My current thoughts are as follows:

• buy a Raspberry Pi 4 computer and have its OS loaded via a live DVD, with the DVD loaded using an external USB DVD drive.

• the live DVD has to be read-only.

• the live DVD will likely be created by downloading the DVD image to a smartphone and then proceeding to burn the image to a blank DVD using the smartphone and an external USB DVD drive connected to the smartphone

• the Raspberry PI 4 device, smartphone, and DVD drive would be bought brand new in such random and physical ways so as to thwart MITM (man-in-the-middle) attacks (this involves picking randomly-selected units from a physical store).

• the correctness of the live DVD can perhaps be better ensured, by doing the following:
  • 1) obtain the image and/or disc in several ways where at least one of the ways does not include relying on the smartphone's internal SD card or other similar NAND flash technology (NAND flash is perceived to be a point of attack);
  • 2) load the OS using each disc in turn;
  • 3) after each OS load (i. e. after each boot), make sure all the disc images match using the software loaded within that loaded OS session/boot;
  • 4) if every check indicates the DVD images are the same then probably nothing to worry about.

• Multiple backup copies of the live DVD can be stored for safe keeping in different locations. This provides a means for checking that any one copy hasn't been maliciously replaced by a hoax live DVD

• the Raspberry Pi 4 computer will also have a battery pack, on which to run in a low-power state when it is not being used. This will ensure that the DVD drive is not needed every time a new computer session is started, because the OS will be loaded entirely into the RAM (using piCore), and when the computer is not used, it will simply be put to 'sleep'. It will also behave as a tamper-evident mechanism, as if the computer is interfered with whilst in the low-power state, this will likely corrupt the state (contents of the RAM or otherwise), and that will likely manifest itself as not being able to log-in into the powered-on system or the system being no longer in "sleep" mode but instead in a completely shutdown state. If the system state is corrupted, a "reboot" would perhaps be needed to 'wipe' the corrupt state clean. To ensure valuable data isn't stolen from the RAM whilst the device is not in use, one of the following methods would be employed: 1) data stored in RAM would always be in an encrypted form; 2) segments of RAM used for the storage of sensitive data would be blanked (zeroed) before putting the device to 'sleep'; 3) both of the methods 1 and 2 would be used together for even higher security. If the whole OS when loaded into RAM, is mostly stored in that RAM in an encrypted state, the system state could perhaps be more easily corrupted through slight tampering, and therefore provide a better tamper-evident mechanism.

• Once per week, assuming no tampering is detected in the system, the system would be used to reinstall the DVD drive's firmware. This would help to ensure that the DVD drive remains a trusted device.

• the computer would be used to log-in to cloud-hosted DaaS (Desktop as a Service) services, meaning that the Pi's limited computing power would not really be much of a concern. There would then be reliance on the security provided by the DaaS provider. The security of the DaaS--normally speaking--would be expected to be quite high; they would generally have much more resources for ensuring this.

• such a set-up would rely on the security of the "TLS cryptographic security certificate" system. Because certain certification authorities would likely be less trusted than others, perhaps only a select few security certificates would be regarded as trusted and used for computing over the internet. In order to stay up-to-date with the certificates in the case of accidental power loss, new certificates would be saved to read-only DVDs, perhaps at the end of each day or each week.

• A USB cryptographic security key would be used in conjunction with a password, to log-in to the DaaS services. Passwords would be changed every now and then

• These methods deliberately avoid NAND flash (as present in SD cards), because of perceived security risks in them. The only time when NAND flash is used locally, is when downloading through the smartphone (smartphones have internal SD cards), however, because of the random-selection principle, there's a good chance that such internal SD cards can be trusted. Even if they cannot be trusted, the live DVD can also be obtained in ways that don't rely on NAND flash. Such obtaining, in conjunction with the DVD image checks mentioned earlier, should mitigate any risk associated with NAND flash.

• Because peripherals like the computer screen, mouse, and keyboard, can be points of attack for adversaries, such devices would be purchased in a similar way to how the Raspberry Pi device, the smartphone, and external DVD drive, would be purchased. By doing so, they would then be able to be trusted. If any such device contains firmware, perhaps the firmware would be able to be reinstalled (to overcome malware attacks in the firmware) in the same way as the DVD drive's firmware should be able to be reinstalled.

• The low cost and high availability of the Pi device is desirable. The high availability makes the random-selection principle stronger and easier to employ. The low cost means that if it really is needed, a new unit can be bought as a replacement, probably in those cases where security may have been compromised in a significant way.

• To be even more sure that the Raspberry Pi hardware has not undergone tampering, or been maliciously replaced with a deceptive fake, certain physical-property authentications can be made of the hardware. For example, using visual inspection, the device can be compared with downloaded photos of how it is supposed to look. Other measurements might be weight, X-ray images, etc. To overcome attacks targeted on the purchases of a specific person, maybe five units of the Pi device can be bought, and then four units chosen at random returned for full refunds.

• The equipment would be locked-up when not in use, and other non-computer measures would be used for things like tamper evidence and prevention of illegitimate password capture (capture done perhaps by means of hidden cameras).

I know people may say that such a high-security system is just a sign of paranoia, but I think it's a good idea to aim high; I'd rather have too much security than too little (at this stage).

Many of the above ideas are documented in the Wikibooks book, that can be accessed at: https://en.wikibooks.org/wiki/End-user_ ... liminaries

If you are able, please provide comments and feedback, on my overall idea, and on the individual ideas.


Thanks,


Mark F

[jamesh]

I doubt a DVD drive will be fast enough to make it usable.

You don't need to do the whole rigmarole of using a smart phone to program the OS. As long as you are sure the otriginal IMG is correct Raspberry Pi imager will verify what you put on the destination media is what was in the original file. Or if you don't trust us, use 'dd' in Linux as that won't be defective.

There is no low power state on the Pi so the battery backup won't be necessary. You should boot each time.

[karrika]

There is USB-SSD drives available with physical read-only switch. One brand is Kanguru. But you could also just get USB thumb drives with a physical write-protect switch.

If you get one of those 8G Pi4's then you could boot from the read-only SSD and have the filesystem completely in RAM. If the unit gets infected the writes have been to the RAM filesystem.

I do not know what "business purposes" means to you. One good idea is "Security by separation".

Perhaps you could have one pi dedicated to managing your bank account. It could have all ports closed and only be used to have https connects to the bank. No facebook, emails or other sources of infection.

You might also have a separate local NAS for storing your photos and texts. Perhaps a separate Pi that is not networked could be used to interacting with the NAS drive. Especially in these days with cryptolocker attacs it is good to keep stuff separated from infections.

I have one Pi at home that only monitors the bus stop I use daily. It has been running for years without problems. The only thing it does is to wake up when I touch the screen and then it shows the next 20 buses with disruptions in traffic. I consider this design very stable and reliable. Well, it probably runs wheezy or jessie and it has not had any updates in ages...

[ejolson]

I have perhaps a somewhat unusual Raspberry Pi project in mind.

Sorry your other computer was hacked. It would seem, however, this experience has lead you to a project that might be of use to many people.

A factor to take into account with a Pi 4B is the onboard user-programmable boot firmware that wasn't present in previous models. Fortunately, the firmware can be write protected by setting some bits in a register and then soldering a jumper to the board. This would need to be done using verified tools before the Pi was connected to the Internet.

While a read-only DVD could be secure, I agree it may be slow. More importantly, from a security point of view, using a mobile phone to download and burn the DVD is a significant risk. My suggestion is to use standard Raspberry Pi OS that has been tested by the multitude and then secure it by setting it to overlay mode and booting it from an encrypted read-only network block device mounted from another computer.

Note that the other computer does not need to be secure because the image stored there is encrypted. Moreover, even though the Pi knows the key, it can not modify the image because the server only gives it read access. While a targeted attack could coordinate the compromise of the Pi and the server to allow the system image to be modified anyway, it would be possible to set up a third system that monitors the read only status of the network block device to help mitigate such an attack if necessary.

Since the 4B has gigabit Ethernet and a fast processor, it is my experience that an encrypted network block device is almost as fast as a local SD card.

[MarkJFernandes]

I doubt a DVD drive will be fast enough to make it usable.
...

Hello Jamesh.

The OS would be running from RAM. Initially it would be loaded to RAM from the DVD drive, so that would be the only time when any DVD-drive bottleneck would kick in. piCore (https://iotbytes.wordpress.com/picore-t ... pberry-pi/) should hopefully allow such "running from RAM" to happen.

....
You don't need to do the whole rigmarole of using a smart phone to program the OS. As long as you are sure the otriginal IMG is correct Raspberry Pi imager will verify what you put on the destination media is what was in the original file. Or if you don't trust us, use 'dd' in Linux as that won't be defective.
...

SD cards are a point of attack. See https://www.bunniestudios.com/blog/?page_id=3592 for more about this. The SD card firmware can be maliciously reprogrammed, and it's very hard for general users to verify the firmware or to reinstall it. Additionally, SD cards may have many redundant memory cells (because of the nature of NAND flash), in which malware can be concealed as well as where stolen data can be kept. In further addition to this, it doesn't seem clear how one can easily tell whether a particular SD card has embedded WiFi tech in it or not, if the outside markings indicating such are removed. Such hidden tech, can mean that the SD card (according to my thinking), may secretly transit data in a wireless fashion to nearby receivers. Nor is such embedded WiFi tech expensive (from my investigations).

It's not just a matter of trusting `dd`...

...
There is no low power state on the Pi so the battery backup won't be necessary. You should boot each time.

According to viewtopic.php?t=243421, there does appear to be a low power state for the Pi 4. The thread also indicates that you can use a battery. Keeping the computer constantly on, and logged-in, as described, is a deliberate security mechanism for providing tamper evidence (and also consequently to deter tampering attempts).


Kind regards,


Mark F

[epoch1970]

FYI. On this forum, when guys with a green badge say something, they usually know what they are talking about.

[MarkJFernandes]

There is USB-SSD drives available with physical read-only switch. ... But you could also just get USB thumb drives with a physical write-protect switch.
...

Hello Karrika.

The problem with SSD drives and thumb drives (as with SD cards), is that they all rely on NAND flash, which is a specific point of attack that I would rather avoid (see my reply to Jamesh at viewtopic.php?f=41&t=286049&p=1730928#p1730928).

The chapter on "Digital Storage" hosted at https://en.wikibooks.org/wiki/End-user_ ... al_storage, tries to analyse the security strengths and weaknesses of different forms of digital storage. Read-only optical media using the same DVD drive again and again, appears to be fairly secure from that analysis. Punched card and ticker tape might be even more secure (not much detailed yet in the chapter), but trying to get that up and running would probably take too long; to store enough data, perhaps a microfilm format could be used....

...

.... One good idea is "Security by separation".

Perhaps you could have one pi dedicated to managing your bank account. It could have all ports closed and only be used to have https connects to the bank. No facebook, emails or other sources of infection.

You might also have a separate local NAS for storing your photos and texts. Perhaps a separate Pi that is not networked could be used to interacting with the NAS drive.
...

I agree that "security by separation" is a very good principle to employ. I'm currently using a paper cipher for my business account password, that I change weekly. Once the paper cipher is locked-up in my safe, it's impossible for me to log-in into my business account, which helps to ensure security for my business affairs. Hardware separation as well (as you have outlined) is a good security principle.


Kind regards,


Mark F.

[msl]

I have perhaps a somewhat unusual Raspberry Pi project in mind.

Hi, Mark. How are you going to separate pieces of firmware you trust and don’t trust?
Raspberry Pi 4 has several blobs with closed sources for:
- boot code
- PCIe-USB bridge
- WiFi
And those are 3 different vendors

[MarkJFernandes]

I have perhaps a somewhat unusual Raspberry Pi project in mind.

Hi, Mark. How are you going to separate pieces of firmware you trust and don’t trust?
Raspberry Pi 4 has several blobs with closed sources for:
- boot code
- PCIe-USB bridge
- WiFi
And those are 3 different vendors

Hello msl,

That's an interesting question. Basically, I'm just trusting that the Raspberry Pi 4 firmware, and NOOBS OS, are secure as is. There are probably plenty of hackers around trying to figure out the security vulnerabilities of the Pi device, and I'm partly relying on their good work in publishing such security vulnerabilities. I'm looking for enough security for my purposes...

Regarding the WiFi, I suppose I could supply WiFi capabilities through a dongle instead. Would that overcome firmware vulnerabilities for the WiFi?

Didn't realise they had closed-source firmware blobs... would have thought the Pi Foundation would try to do everything open-source. From a security perspective, I would favour open-source code. Can the firmware be replaced with open-source firmware..?


Thanks,


Mark F.

[msl]

Regarding the WiFi, I suppose I could supply WiFi capabilities through a dongle instead. Would that overcome firmware vulnerabilities for the WiFi?

Wifi dongle either has own firmware or using OS provided closed source blob. And this WiFi dongle is working over closed source PCIe-USB bridge blob

Didn't realise they had closed-source firmware blobs... would have thought the Pi Foundation would try to do everything open-source. From a security perspective, I would favour open-source code. Can the firmware be replaced with open-source firmware..?

Broadcom SoC documentation delivered under NDA. Releasing sources for firmware is NDA violation.

Disclaimer: I’m not security expert and have no idea if WiFi or USB bridge firmware can inject code to ARM or do any other harmful things, but WiFi is definitely MITM

[MarkJFernandes]

...
Wifi dongle either has own firmware or using OS provided closed source blob. And this WiFi dongle is working over closed source PCIe-USB bridge blob

...
Broadcom SoC documentation delivered under NDA. Releasing sources for firmware is NDA violation.

.... WiFi is definitely MITM

Yes, I agree, and it is slightly worrying now you have brought it to my attention. Thinking of lobbying government, perhaps through the BCS organisation, to try to force hardware vendors to supply "trustable hardware"... because at the moment, I'm very much concerned at how untrustable hardware appears to be.

Think EU legislation permits limited reverse engineering... never done it myself, but could that be something to try to figure out what the firmware is doing? Never programmed low-level, except when I was student and that was hardly anything really.


Kind regards,


Mark F.

[ejolson]

Disclaimer: I’m not security expert and have no idea if WiFi or USB bridge firmware can inject code to ARM or do any other harmful things, but WiFi is definitely MITM

I'm pretty sure the USB bridge can DMA with abandon anywhere in the first 1GB of system memory.

I just looked at the section in the book about using randomly selected burner phones to download operating system software. Even though phones are less secure in my opinion than a properly audited computer, such randomisation could have value if the phone can be activated without connecting it to any personally identifiable information.

In particular, it is counter productive to take a randomised phone and connect it to the WiFi at home. Not only does that immediately identify who the phone belongs to, but generally compromises the home network. To help ensure an authentic download, the randomised phones further need randomised IP numbers to use when downloading the software. Alternatively, call up a friend in Finland and ask them to verify the sha hash of the install file. Then recklessly proceed with dd and a random SD card.

[karrika]

I'm looking for enough security for my purposes...

This is a sensible approach.

I assume that you are looking for a system that is secure and convenient to use.

The point is that you want to minimize the frequency of attack attempts. And you want to minimize the hazard that a successful attack or malfunction does to you.

Kali linux is a very secure oriented distro that you could study to reduce the frequency of attacks. But Raspi OS can also be hardened if you want to take this route.

Good backups that are off-line is a good counter measure against most attacks.

It may actually be easier to create fast ways to recover the systems after an attack than trying to create a super-secure system that can withstand everything.

The reality is that everything can be hacked and all CPU's may have malicious code in the chip already. But the chance that this affects you is really small compared to a broken SD card.

If you are interested in studying safety and risks there is some standards like ISO 27001 and for systems controlled by computers IEC 61508.

Basically they tell that:
Risk = Frequency * Hazard
Applying security patches to your Pi is a good idea.
Don't put all your eggs in one basket.

[msl]

Yes, I agree, and it is slightly worrying now you have brought it to my attention. Thinking of lobbying government, perhaps through the BCS organisation, to try to force hardware vendors to supply "trustable hardware"... because at the moment, I'm very much concerned at how untrustable hardware appears to be.

Even without conspiracy theories silicon manufactures would prefer to embed processors to peripheral ICs. It gives more flexibility and option to add new features or fix bugs instead of new silicon revision. At me same time manufactures don’t want to release sources, because it’s extra cost and only 0.0...1% of customers need it

[ejolson]

Good backups that are off-line is a good counter measure against most attacks.

It may actually be easier to create fast ways to recover the systems after an attack than trying to create a super-secure system that can withstand everything.

One important question when creating an effective offline backup of your bank account is whether to use silver coins or gold. For many people the main concern is not recovering the data but recovering from the damages that result from the data being stolen or surreptitiously modified.

For me computer storage devices lost transparency in how they worked around 1984 when IBM introduced the ATA/IDE disk drives with integrated controllers. After the pig escaped from the sty, it quickly grew and soon had advanced on-board processors with user programmable firmware. Along these lines the level of complexity has increased dramatically between the 3B+ and the 4B: There was no user-writable persistent memory on the 3B+ while the 4B has at least one if not two SPI-attached EEPROMs that contain the boot loader and firmware.

Although I've not seen a proof of concept that installs malware in the Pi EEPROM and then protects it from the standard update procedure, I've also not seen a description for using some sort of JTAG connection to ensure a fresh factory image is written to that EEPROM. As hardware and software gets more and more complicated it is difficult for humans to audit for correctness of design and implementation.

While inconsistent with his stance against the BASIC programming language

Simplicity is prerequisite for reliability.

Complexity is why humans react to things in different and unexpected ways; however, such complexity is also related to biological resilience, at least to everything so far except the coronavirus.

Back on topic, people seeking Dijkstra's true simplicity often find themselves in the world of retro computing or even worse the RISC-V open-source CPU. On the other hand, from a practical point of view, the Raspberry Pi Zero is about the simplest computer currently available that will boot Linux and run a web browser powerful enough to use for online banking.

[cleverca22]

of note, there is the https://github.com/librerpi/rpi-open-firmware project can boot linux on pi2 and pi3, without any blobs being involved

pi4 is harder, due to many factors:
* blob(even when compiled from open source) must be signed with an hmac-sha1 key
* the ddr4 controller is unknown, so drivers would have to be written first, or you dont even get ram
* the ddr4 controller has its own blobs!!!
* the usb3.0 controller also has its own blobs

[bensimmo]

Phone, use your own OS on it, use it with encrypted UFS drive. (most phone and laptops come with encrypted drives now, no idea how they work).

Are torrent downloads more secure w.r.t getting a correct image, assuming they torrent and hash from a secure original server. iirc it suppose to be self correcting, but it has been a very very long time since I looked i.e. back near the start of it all.

By pass internal storage and write directly over USB to your DVD, if caching can be bypassed. You've (or a trusted 3rd person) has written the OS so I guess you would know.

Don't forget Bluetooth on the Pi, often forgotten about and people talk WiFi as an attack vector.
What about the GPIO leaking data? Would you notice? If they can?

[bensimmo]

Pi image authentication, down fall is they can change small things during its production time. move things around, modify faults, drop components to make it cheaper, if deemed not necessary. So a new one may very slightly different.

[MarkJFernandes]

...
I'm pretty sure the USB bridge can DMA with abandon anywhere in the first 1GB of system memory.

Very concerning...

I just looked at the section in the book about using randomly selected burner phones to download operating system software. Even though phones are less secure in my opinion than a properly audited computer, such randomisation could have value if the phone can be activated without connecting it to any personally identifiable information.

In particular, it is counter productive to take a randomised phone and connect it to the WiFi at home. Not only does that immediately identify who the phone belongs to, but generally compromises the home network. To help ensure an authentic download, the randomised phones further need randomised IP numbers to use when downloading the software. ...

Whilst I concede that there is a risk when connecting to home WiFi, the hope was that the TLS cryptographic certificate-based security would be enough to buoy sufficient security for downloading the ISO image. Am I wrong about this? The worst I would have thought an adversary could do, would be to block you from downloading, but then that would be evident to you and you wouldn't be deceived (such deception perhaps being the downloading of a malware-infected download).

The whole system inevitably places some level of trust that the WiFi connection, ISP, and DaaS services, are able to deliver their services. They are all points of attack, but at least with respect to paid services, you can pester the providers to make sure they are properly delivering the services; you can to some extent get them on your side, working with you, to establish a secure-computing environment. The WiFi equipment could be safeguarded in the same manner as the Raspberry Pi device, DVD drive, smartphone, etc.

It does depend on what kind of attacks you are encountering. You seem concerned with blatant attacks whereas I'm more concerned with those hidden kinds of attacks that are elusive. With blatant attacks, you can report odd goings-on to the police with such possibility in fact possibly acting as a deterrent to the attacks from ever taking place in the first place.


Kind regards,


Mark F.

[MarkJFernandes]

I'm looking for enough security for my purposes...

This is a sensible approach.

...

Kali linux is a very secure oriented distro that you could study to reduce the frequency of attacks. But Raspi OS can also be hardened if you want to take this route.

Good backups that are off-line is a good counter measure against most attacks.

It may actually be easier to create fast ways to recover the systems after an attack than trying to create a super-secure system that can withstand everything.

The reality is that everything can be hacked and all CPU's may have malicious code in the chip already. But the chance that this affects you is really small compared to a broken SD card.

If you are interested in studying safety and risks there is some standards like ...

Basically they tell that:
Risk = Frequency * Hazard
Applying security patches to your Pi is a good idea.
Don't put all your eggs in one basket.

I probably agree with everything you wrote. It's good to identify the broad security principles rather than just getting bogged-down with the "nuts and bolts" of the security.


Kind regards,


Mark F.

[MarkJFernandes]

... Thinking of lobbying government, ..., to try to force hardware vendors to supply "trustable hardware"...

... silicon manufactures would prefer to embed processors to peripheral ICs. It gives more flexibility and option to add new features or fix bugs instead of new silicon revision. At me same time manufactures don’t want to release sources, because it’s extra cost and only 0.0...1% of customers need it

I hear what you're saying. But "trustable" hardware is important and is important enough for industry to change their products and practices. I don't think it would be that hard either. I'm sure there would be many customers willing to pay a bit more for more "trustable" hardware.

Not all customers would need the source, the source could just be malware-checked by various independent bodies, and the published results would help customers determine their purchasing decisions.


Kind regards,


Mark F.

[fruitoftheloom]

I have perhaps a somewhat unusual Raspberry Pi project in mind.

Hi, Mark. How are you going to separate pieces of firmware you trust and don’t trust?
Raspberry Pi 4 has several blobs with closed sources for:
- boot code
- PCIe-USB bridge
- WiFi
And those are 3 different vendors

Hello msl,

That's an interesting question. Basically, I'm just trusting that the Raspberry Pi 4 firmware, and NOOBS OS, are secure as is. There are probably plenty of hackers around trying to figure out the security vulnerabilities of the Pi device, and I'm partly relying on their good work in publishing such security vulnerabilities. I'm looking for enough security for my purposes...

Regarding the WiFi, I suppose I could supply WiFi capabilities through a dongle instead. Would that overcome firmware vulnerabilities for the WiFi?

Didn't realise they had closed-source firmware blobs... would have thought the Pi Foundation would try to do everything open-source. From a security perspective, I would favour open-source code. Can the firmware be replaced with open-source firmware..?


Thanks,


Mark F.

NoobS is not an Operating System par-se it is an installer / chooser, which since May 2020 is not recommended. The supported Operating System is Raspberry Pi Operating System which is Debian Linux based.


The SoC of the Raspberry Pi SBC is from Broadcom, whllst the WiF, Ethernet and USB Chipsets are sourced from 3rd parties.


Raspberry Pi Trading are responsible for Hardware, and the family of SBC's has never been open-standards.


If you need open standards then 99boards:

https://www.96boards.org/about/


Bottom line is you are asking about using a product in a scenario which was not envisage to be of importance 15 years ago or even today......

[msl]

I'm sure there would be many customers willing to pay a bit more for more "trustable" hardware.

Paying more money will not guarantee anything. Search for Crypto AG scandal: https://en.m.wikipedia.org/wiki/Crypto_AG

[MarkJFernandes]

...
One important question when creating an effective offline backup of your bank account is whether to use silver coins or gold. For many people the main concern is not recovering the data but recovering from the damages that result from the data being stolen or surreptitiously modified.

Lateral thinking when it comes to security, seems important.. yes, thinking in terms of financial compensation for loss may be part of an overall security approach.

For me computer storage devices lost transparency in how they worked around 1984 when IBM introduced ....

... I've also not seen a description for using some sort of JTAG connection to ensure a fresh factory image is written to that EEPROM.

Yes, such re-installation facility is a good idea. I was assuming that the Pi 4 EEPROM could be "factory reset" by reinstalling the firmware. Are you implying this is not possible? Perhaps it would be better to go for a Pi 3 then... but then is the Pi 3 capable of USB booting?

... As hardware and software gets more and more complicated it is difficult for humans to audit for correctness of design and implementation.
...

Legally obliging all hardware vendors to publish the source code for their firmware, would go some way to gaining people's trust. In addition to this, obliging them to publish all documentation for such source code, would perhaps help even further. In further addition to this, the correctness of algorithms could be proved using mathematical techniques, and perhaps you could oblige vendors to do this proving. It is probably generally easier for the code writers to prove their code is correct, than for third-parties to uncover malware in the code. In addition to this, all firmware could be loaded using some kind of microfilm technology. The microfilm should be able to be removed, and visually inspected for correctness. The tech loading the microfilm, would be standard amongst many vendors, so you would gain efficiencies in security checks because you wouldn't have so much variety in the hardware needing to be checked.

With AI, there are further aids to help with auditing.

...
Back on topic, people seeking Dijkstra's true simplicity often find themselves in the world of retro computing ...

During the writing of the Wikibooks book, I do have to admit that some things from retro computing did seem appealing in terms of security. Wondering whether computer security has gone down over the years....

On the other hand, from a practical point of view, the Raspberry Pi Zero is about the simplest computer currently available that will boot Linux and run a web browser powerful enough to use for online banking.

Yes, it's one of the things that drew me to Raspberry Pi tech. Visual inspection is also good in the devices, to detect better any hardware tampering. Having not many components to check, is also desirable. It's high popularity also tends to establish a level of trust with the technology.


Kind regards,


Mark F

[MarkJFernandes]

of note, there is the https://github.com/librerpi/rpi-open-firmware project can boot linux on pi2 and pi3, without any blobs being involved

pi4 is harder, due to many factors:
...
* the ddr4 controller is unknown, ...
* the ddr4 controller has its own blobs!!!
* the usb3.0 controller also has its own blobs

Thanks for posting this. Whilst I generally favour open-source firmware, I would have to be satisfied that this code is actually safer than the closed-source proprietary code. It being published in GitHub is a good step towards establishing trust. If the code is not popular though, this could be indication that it received little peer review to establish it as being able to be trusted.

USB boot is very important for the project (under the current thinking), so these earlier Pi models would have to be able to do such booting for them to be potentially used.


Thanks,


Mark F.