I am saving my pennies to build my pc that will be relatively secure and private. Raspberry pi b+ Cell shield add on for above Prepaid sim (paid in cash) Bluetooth stick Wifi stick (looking for one with least security issues but they all seem to be in bed with Al-Shaitain) Lcd screen Sdr transceiver Punch the security holes that you see or possibly give me better substitutes Thanks for your time TTFN
On Wed, Apr 15, 2015 at 04:18:11AM -0400, Edd thompson wrote:
I am saving my pennies to build my pc that will be relatively secure and private. Raspberry pi b+ Cell shield add on for above Prepaid sim (paid in cash) Bluetooth stick Wifi stick (looking for one with least security issues but they all seem to be in bed with Al-Shaitain) Lcd screen Sdr transceiver
Punch the security holes that you see or possibly give me better substitutes Thanks for your time TTFN
What is your threat model?
The SOC in a raspi is probably no worse than the rest, but consider that the natural entropy available (for Crypto) to a SOC is much lower than a multi-component system like a laptop or tower. The Raspi 1.xx has an onboard entropy chip you can enable, if you trust it, and there'll be a new device in /dev you can read raw entropy from. Write that to /dev/random to seed the system pool and use /dev/urandom as your actual source. Personally I'd draw from several sources to feed /dev/random: an internal hash-chain (quick Python script) (re)seeded on a password and urandom periodically, the hardware entropy generator, Ubuntu's seed server.. don't trust one source, mash them up once a minute/hour and feed them to /dev/random. On 15 April 2015 09:18:11 GMT+01:00, Edd thompson <blukami@gmail.com> wrote:
I am saving my pennies to build my pc that will be relatively secure and private. Raspberry pi b+ Cell shield add on for above Prepaid sim (paid in cash) Bluetooth stick Wifi stick (looking for one with least security issues but they all seem to be in bed with Al-Shaitain) Lcd screen Sdr transceiver
Punch the security holes that you see or possibly give me better substitutes Thanks for your time TTFN
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04/15/2015 02:05 AM, Cathal (Phone) wrote:
Personally I'd draw from several sources to feed /dev/random: an internal hash-chain (quick Python script) (re)seeded on a password and urandom periodically, the hardware entropy generator, Ubuntu's seed server.. don't trust one source, mash them up once a minute/hour and feed them to /dev/random.
I've gotten some success with a USB enabled Geiger counter (https://www.sparkfun.com/products/11345). A little Python was used to open the USB serial device and measure the amount of time that passed in between characters being emitted, hash them, and cat the hashes into /dev/random to give the kernel pool a little more to work with. The unit's pretty large (larger than the RasPi) and needs a housing of some kind to really protect it. I wouldn't use it for an HSM but for experimenting at home it works decently well. Now I just need to get around to learning SciPy to profile the output of /dev/urandom for biases... - -- The Doctor [412/724/301/703/415] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ Good enough is the enemy of the best. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVLqfpAAoJED1np1pUQ8RkQXkP/i22Gu/cum2rTJEIxJpy2FAk QML6bkLFUC5irii+lvZWppAgCjZ/08sI4R0CVN8HNsiJ4YsZnmvcQSb6uiOZ2h7v YdYBlyb1g8xJZo3GYNyiZ/VaUvGIxa9tx9vBVBNTupQ/zvGIdlYxPsKFa8X8uqNX PgcECa1jO7+sZ+IRbZ2csv3xNVJ9zoQ71SrYrIbTFAl93DJUpwFKqGyoybg5xlk3 4FJ1Fxjataa/VyHg0D02luWehxaoasvaKBbv9Jjuri5dPK4dJFJ87/zpE5GsDJD0 SxvWpK9zoss0XdQ1mgPD9/sRUvz38EjeAtIwUaci6UYEGlAR+CIabHdmvK8ozfqa UKLQ0kUA64KyBt7pZqMR/mPRRqhQwNPoZ+IkO980kcD8/560FLK75Bt8YuunwpUp xMRmt4peHFNoYGrtPkacuvJQ2tgxt+fqVpWEV75MO185pYdBCpEiFVc9vb1SSgJA dKS6JNR38veYC4t1xemWnJWIrB75eDV6iPsLTy2kPP5JwQQjbUDBmIn4HD1NUgLk WVE24trMo804+Ez37Avkgi1c1b8lTcP2BT2NL4c43tkcWZvi6ztp+15F6Yc/2ml2 zFSlEiAqgIilptHN3pY6UlAAej+B0ATRDisWjsRqFx9eM//oB/gicxDA+s4QyLJX fNu4HtxeKg7b97Ss1xaE =waFj -----END PGP SIGNATURE-----
On 4/15/15, The Doctor <drwho@virtadpt.net> wrote:
... I've gotten some success with a USB enabled Geiger counter (https://www.sparkfun.com/products/11345). A little Python was used to open the USB serial device and measure the amount of time that passed in between characters being emitted, hash them, and cat the hashes into /dev/random to give the kernel pool a little more to work with. The unit's pretty large (larger than the RasPi) and needs a housing of some kind to really protect it. I wouldn't use it for an HSM but for experimenting at home it works decently well.
the Pi has built-in camera capability; see the other threads about LEDs into a CCD for stochastic measurement at high rates. as amusing as ionizing radiation may be for entropy generation, there are much more practical routes :P
Now I just need to get around to learning SciPy to profile the output of /dev/urandom for biases...
DIHARDER over gigs will give you a great gist. is there a specific type of (transient) bias you're after?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04/15/2015 09:16 PM, coderman wrote:
the Pi has built-in camera capability; see the other threads about LEDs into a CCD for stochastic measurement at high rates.
I did. This is an older project, from before the CCD measurement threads.
as amusing as ionizing radiation may be for entropy generation, there are much more practical routes :P
Maybe. It's been an instructive exercise, if nothing else.
DIHARDER over gigs will give you a great gist. is there a specific type of (transient) bias you're after?
I just want to see what might or might not be in there to satisfy my curiosity (ala the visualizations in Michal Zalewski' _Strange Attractors and TCP/IP Sequence Number Analysis*_). - -- The Doctor [412/724/301/703/415] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ Only those who risk going too far find out how far they can go. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVL/LGAAoJED1np1pUQ8RkjHwP/3vgh9I1w5BfzBCcd/X+gmjG HowmLlba5lfSYm1Bu0/rN+G8AFnNQ9Sn3UvSUseHrYwuTyEq1dKv3irEqcF+A0vr UKxiznNprdYwd78BIIrA0GRZUrg+lQw4LzYW4t8u/ExbjTJIC075Cw6In6GOQ4mW DbYoEWrXBt9GZMHtQJqbUbsF+k8QHCPJcYam9WaolBNSMgm+GCk86U6GjI6FGS7A vJ6A6tjtaJD6S4Sh7V1cn9euwohDWo5zEQj+qUmEFVbE6D5vlmmSMwLSYBw85d0G +MYMzdTntgWaDLJ59KE1jfoCHE+iRROX/0pBj4jrXVqkqsitS5c/gRzJ+I2qWGPK xb6y8y3XT/y1fSZyxnwgdfzVD477JgRTsnFrGVgPA8Uezf0kf9+n3umzmbi2rUux AeRD1OKN024U7wV2YKNkbFlMBbuoXn/WZfDIi/UWcz85/MGJA5Sinw1MhDkRuPeJ oayd0iPHXLs77iCwzVSQlOGOZxx2EYybEuc9DvBKwQ9PLwVXnKAsomUHWjiW2ITM ICZ+sZ7YSyGmB/aw5djXNMblYxoY8DLQBrk4d2x7umixFOvbMr9KrS1/hCl8p7zR SNoJHT0/mNJYGHcBsOHU/tZGNO3T0MGaZuplBd9tpuUzH1kuOuzqkgcKwbH7Ii85 9MxM5clkfJpZOaXnxyf7 =nvD+ -----END PGP SIGNATURE-----
On 4/16/15, The Doctor <drwho@virtadpt.net> wrote:
... I did. This is an older project, from before the CCD measurement threads.
it would be interesting to see what throughput you get with a CCD implementation; i'm looking for a faster XSTORE :)
I just want to see what might or might not be in there to satisfy my curiosity (ala the visualizations in Michal Zalewski' _Strange Attractors and TCP/IP Sequence Number Analysis*_).
a classic! how about http://binvis.io/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04/16/2015 08:39 PM, coderman wrote: I'll have to play around with that, then. Thanks for the link, I'll play around with it a little this weekend. - -- The Doctor [412/724/301/703/415] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ "Television is reality, and reality is less than television." --Brian O'Blivion -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVMUM+AAoJED1np1pUQ8RkBiEP/jm/SmFpRm58YR3W/wyN5Uba p4dxD69I+LnfEq7rbqcRKclys46t4cScrOc68/F5dMyrf71cgqJzNrNIAHXSYpOP ZuUmgf083jwg05lhpQOctcsq1Gc4qLIUmNA0diX4/p9N77fj6zo13L4qdbTNDvVk vCNtGa72JTsejUQmzzh49twDtw6fWbpAWCAJLhCARPKLgsyTEilchmmLGiGZl2zK U0UDwIJ6eTBb7I17HS/Ea5vV/mx6hiXpVeUDP6lsTG8S/bONHBQtom3cvEcWtyFK TzfJHw58j8fxXxOZdYYFMGx8MvOKrP+T7spn8zCVZmJQRH9EPJvarrl+L+6gqVQ4 G9neqcSu2Bj1DYgWPVKsnZG30NgQBLXUAcrarqU/TK0QwyAUZCFinT9kcaygeU0E 9sYTnLClmcp1pyVifKxXUTlRauHANuNimMMypO9D1V4CGHelinGfvvN1JagsP8G5 FH6oFXHhjUUK9kznARilkxFXSjZB1i2PrNP/coIcmkptm/CbSf/y123z8QjHPzbB 5ipHGkeulWSOjJ0I6csqfMcLMMNRTQ/2V9SmzMM/np31E1/988lUKYDkxtRdsPsy DX+JL0nGPk+mDkKxccwgfsf+hqEa2DHMGPgZnZNYOI9MpcKnPbnOmGCMAe6xtPPG TZKX4ndtKpgmgr/O9uXT =/iUn -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04/16/2015 08:39 PM, coderman wrote:
it would be interesting to see what throughput you get with a CCD implementation; i'm looking for a faster XSTORE :)
I'll have to play around with that, then.
a classic! how about http://binvis.io/
Thanks for the link, I'll play around with it a little this weekend. - -- The Doctor [412/724/301/703/415] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ "Television is reality, and reality is less than television." --Brian O'Blivion -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVMUM/AAoJED1np1pUQ8RkRJEP/1MzRd1W7q8uqwh/EEukkGYp qasUkk1kzXEV7IwANS2aDH5GmJGVFJzg2UwHTly/ZJniLx72weF219708GO3CG66 ATPCh7h0YtGw9VaV57a5xZQAX+CVWS32JraPKSkR6AK9XfNyi0YbXUpfaoBy+zXG 4j2bp8EZIAInXqXx9ZF4xv0Bwypv9RilBGE0YdBY8Wkc+XV2/rD3IpGv2LB2DLsm 8n/58DGhGJCE7MfrHQwdgnaSBCKVGI2mfVo1ws9Y5vq32ddcRzIxz1BPfXhKfUk0 hBF6u8WbfDlH0HaYg/F7e4IXqg9extCQVim/+GEb2DIStFhNPgxWsk76v68kbd0e zCoDwIbqh8cRgZA3V906BE3bLCicpmhQR/4s0fcszHsySLl5mqVz2wg4rzmG2GMZ qgb43A0lLKmZxm3Muy3/VZxHEpQ+0ZrkTm5wPQFaFCqT6wcuBAavA8zBjreA7/Uj oDqxiUFnSc04OytYb840OX+TzEVGzNvhffYj6Ev2VZWJlGhFXHxVeM7x7dopNL3Z xFnGdWRitbac4ZlQIZ9neREga9WRr5C/oBJdT3W8rn6ZL7nLxrYeWfi6B1/RzXOk tSBxxB3aOkawXC+DzyXy8wL6Tf12zTTHzxsM+hDlajklMHb//wFG/2H8v8bzp8qa kdO7/Tg4oNmjpehaKXID =xT7m -----END PGP SIGNATURE-----
2015-04-15 18:05 GMT+09:00 Cathal (Phone) <cathalgarvey@cathalgarvey.me>:
The SOC in a raspi is probably no worse than the rest,
This is what I'm most concerned about! I think the Intel platform is too big to not be exploited (more or less) on the hardware level. I have a very little better feeling about AMD but I don't think it's based on much. The idea that ARM processors are much much smaller and therefore easier to audit makes them less attractive exploit targets. That, and that they've only recently come into use, are build by smaller companies, etc. When you build a SOC around it, well, that's kind of asking for trouble! The best avoidance method I've come up with so far is taking two units, (bitbanging) I2C (or whatever) over the IO pins to do "networking" from one to the other, connect one to the Internet and the other exclusively over those IO pins. That way, whatever exploit is present is VERY unlikely to be triggered. It's... still not 100% of course.. If the exploit is on the relevant IO pins, well, it just might be trigger-able by manipulating the network traffic. Maybe write high every so many bits just to meddle? It's closer then anything else, anyway. As for less paranoid exploits, you have to tell us the threat model! (the cell shield will very likely be remote exploitable, but only by the really bad goodies)
A stand-out problem with trust in Broadcom SOCs like RasPi is the massive binary bootloader. If there's a sploit it need not be hardware based, because there's plenty of room in there for a whole hypervisor arrangement, methinks. On 17 April 2015 08:02:47 GMT+01:00, "Lodewijk andré de la porte" <l@odewijk.nl> wrote:
2015-04-15 18:05 GMT+09:00 Cathal (Phone) <cathalgarvey@cathalgarvey.me>:
The SOC in a raspi is probably no worse than the rest,
This is what I'm most concerned about! I think the Intel platform is too big to not be exploited (more or less) on the hardware level. I have a very little better feeling about AMD but I don't think it's based on much.
The idea that ARM processors are much much smaller and therefore easier to audit makes them less attractive exploit targets. That, and that they've only recently come into use, are build by smaller companies, etc. When you build a SOC around it, well, that's kind of asking for trouble!
The best avoidance method I've come up with so far is taking two units, (bitbanging) I2C (or whatever) over the IO pins to do "networking" from one to the other, connect one to the Internet and the other exclusively over those IO pins. That way, whatever exploit is present is VERY unlikely to be triggered. It's... still not 100% of course.. If the exploit is on the relevant IO pins, well, it just might be trigger-able by manipulating the network traffic. Maybe write high every so many bits just to meddle? It's closer then anything else, anyway.
As for less paranoid exploits, you have to tell us the threat model! (the cell shield will very likely be remote exploitable, but only by the really bad goodies)
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On 4/17/15, Lodewijk andré de la porte <l@odewijk.nl> wrote:
.... I think the Intel platform is too big to not be exploited (more or less) on the hardware level. I have a very little better feeling about AMD but I don't think it's based on much.
The idea that ARM processors are much much smaller and therefore easier to audit makes them less attractive exploit targets. ...
essentially they're all suspect under some level of modest threat (e.g. CUSTOMS interdiction or TAO enabling or ...) so then you get to openRISC on an openFAB with strong chain of custody along every step from sand to structure to send to self(and if you lose proper custody of device that's your problem; see threat models again :) --- https://openrisc.github.io/ http://www.globalfoundries.com/ for openHW? https://en.wikipedia.org/wiki/Chain_of_custody --- oh, and of course the occasional FIB tear-down of fabricated cores to confirm no surreptitious corruptions. pick your favorite hard problem :P best regards,
On Fri, Apr 17, 2015, 6:58 AM coderman <coderman@gmail.com> wrote: On 4/17/15, Lodewijk andré de la porte <l@odewijk.nl> wrote:
.... I think the Intel platform is too big to not be exploited (more or less) on the hardware level. I have a very little better feeling about AMD but I don't think it's based on much.
The idea that ARM processors are much much smaller and therefore easier to audit makes them less attractive exploit targets. ...
essentially they're all suspect under some level of modest threat (e.g. CUSTOMS interdiction or TAO enabling or ...) so then you get to openRISC on an openFAB with strong chain of custody along every step from sand to structure to send to self(and if you lose proper custody of device that's your problem; see threat models again :) --- https://openrisc.github.io/ http://www.globalfoundries.com/ for openHW? https://en.wikipedia.org/wiki/Chain_of_custody --- oh, and of course the occasional FIB tear-down of fabricated cores to confirm no surreptitious corruptions. pick your favorite hard problem :P best regards, So what you guys are saying is... When I go Incognito Mode in Chrome, that little spy guy isn't really protecting me from everyone spying?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04/17/2015 12:02 AM, Lodewijk andré de la porte wrote:
The SOC in a raspi is probably no worse than the rest, This is what I'm most concerned about! I think the Intel platform is too
May I ask what your opinion of LowRISC is? http://www.lowrisc.org/about/ - -- The Doctor [412/724/301/703/415] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ "Television is reality, and reality is less than television." --Brian O'Blivion -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVMUO4AAoJED1np1pUQ8RkaYoP/jviWBHgq+hEWXnKuFqcKZje Un3MX3JZZWopNW0FmTz7JQ3QePsO11gO/QhwZW0G1dUhAfS1cS2GoYp+MLy6QgT7 KtIzpcEk4jyvVgr3WpydKhSwf10iDD0Xat3uRJOTZ0eWJR5pNTb3gEYUYAK/MEsC 1jn0Od70WlkJWZUcp27bfHXVle+wrjb5O0qCLPqt+V4aM7b2Wv9JjLlZQBxjhnQr xd5LRXjIKnrrJLZ1tf/Z4vJLA/nsRaaWS/atpJp0h2bLd9XxzRdDgCiNdx5OeAxl i66JmvtLSZC62eVIOP2tIyicAnxujFK6bNypv80Sp4DlVLSFdcxaqWEBva9HLxll uoCyoIK7v0muCDmrKdcvm1xzovvk6kXKlKWA9gRt0bX3m/ZF2ZkldADK1nKgSVqs TiImvuLAHKHmkKZB9N/dcJ1gZ1/WGZStRhrVeQ/fDmP53dkcCWRD06rXPdb+bM89 URKTPcIZiSWxB0aK/lYcB6fb7DSKPvQTOGsdok+2w8MkQeaZho3FONfWJcJkhsBD 4XJq5PqiAPntNlO04+4amWyxcaaLq9BiYrQC1g7sZ1B3j8wno7SdNVEnGNqpruLd 0IYH5EhRIR1+JwVFVZEaYch95t1BpJKhgAD5rRRZ7BsyYCtolkhC5PVUIR3LZCVG iUvWaKpA8c0rMo/xfMqr =1fOO -----END PGP SIGNATURE-----
On Wed, Apr 15, 2015 at 10:05:30AM +0100, Cathal (Phone) wrote:
The SOC in a raspi is probably no worse than the rest,
I contest this claim. BRCM SoCs are probably not the *worst* SoCs in the market (that distinction probably belongs to Mediatek or a chinese vendor we've never heard of) but they are almost certainly not in the first ranks. Unfortunately I can't make a strong argument as to which SoCs are in the first rank. I'd give some of the TI chips a higher chance, but brand-hunting is not the route to safety -- some of the TI chips are almost certainly as bad or worse. I am concerned about the following -- 1. existing SoCs CPUs certainly have errata (known errors or undocumented "features") that are not disclosed to the public, and never fixed in patched chip releases. Some of these are likely to cause security issues. Previous SoCs (circa 2008) have had undisclosed bugs in instruction decode allowing privilege elevation, for example. Even Intel and AMD, who have a *much* larger team working on these systems than places like Broadcom and Mediatek, still manage to ship security bugs from time to time... I don't give BRCM much of a chance of shipping bug-free silicon. 2. SoCs contain a multitude of "Intellectual Property Blocks" such as a DRAM controller, an Ethernet controller, USB, SATA, AC97 Audio, etc. These are all connected together by an interconnect bus. Each block comes from a different development group, often purchased from a different company. The company that sells you the SoC often doesn't even know what the features and bugs of their purchased IP cores *are*... and that undocumented ethernet core may well have a "feature" that would allow arbitrary access to the interconnect. 3. SoC interconnects don't have much in the way of security. When the Ethernet controller bug lets a Evil Packet onto the interconnect, it's probably just a hop skip and a jump to main memory. -andy
On 4/17/15, Andy Isaacson <adi@hexapodia.org> wrote:
... 1. existing SoCs CPUs certainly have errata ... 2. SoCs contain a multitude of "Intellectual Property Blocks" ... 3. SoC interconnects don't have much in the way of security. ... [ more reasons to isolate SoCs ]
for a not designed to fail bus between SoCs, an SPI based protobuf langsec barier'd link between distinct role oriented isolated SoCs would be very useful. the ways to isolate memory and address spaces is cumbersome in all cases for these platforms, so far. and multi-path / multi-home for these links allows as much capacity as you have physical support for. anything bus based or complex like wireless or wired local area networking are pwnholes, and to be avoided... USB condom mode should not be after market; but a core built-in. these are all well known arguments, and i am preaching to the choir :) [ TrustZone, virtualization extensions for ARM, memory read and write once protections, etc. if you trust these, then direct PCIe 4lane interconnect is best, maybe. ]
On 4/17/15, coderman <coderman@gmail.com> wrote:
... for a not designed to fail bus between SoCs,
an SPI based ... if you trust these, then direct PCIe 4lane
someone else brought up DRAM fill over JTAG, other JTAG based comms. also not unreasonable, even if overkill for this purpose alone.
participants (8)
-
Andy Isaacson -
Cathal (Phone) -
coderman -
Edd thompson -
J.R. Jones -
jonas -
Lodewijk andré de la porte -
The Doctor