Discussion:
m-o-o-t - some decisions
Peter Fairbrother
2006-10-21 03:38:13 UTC
Permalink
m-o-o-t - for when you want to do something secure -

- if you can't do it in m-o-o-t, then it probably can't be done securely -
if you can do it in m-o-o-t, in m-o-o-t it can _only_ be done securely :)


m-o-o-t is a liveCD OS+Apps designed especially for security against
coercive attacks (people demanding keys or plaintext, eg through legal
threats or threats of torture). but more to be secure Overall.



I /digress:

People have complained that I only post when I'm drunk.

It's true, mostly I am drunk when I post. I'm sorry about that - I don't
drink most of the time (now .. I , well..), but when I am not drunk I am
working, and far too busy to post. So you don't get to see many posts from
me when I'm sober.

But I think about the content of the post when I am sober, just mostly I
write them when I am drunk and have the needed free time and urge to write,
not think. Not always, but mostly. :)

Sometimes I don't get them right - sorry -

digress/




Decisions, decisions:


[1] Base OS:


OpenBSD, anotherBSD, RedHat/*buntu Linux, Windows, customOS.




I do not have the resources to do a customOS (rather than adapting an
existing OS). I'd like to, but writing an OS from scratch is more work than
I can manage with present resources. And I'd like to include a new secure
language (ouch!) too if I was going to do that ...


I eliminated Windows because we can never know what Windows is doing, as the
source is closed. Not that open-source means we are always sure what the
program is doing, but .... it helps



I also easily (ha!) eliminated anotherBSD, because OpenBSD would give more
security than anotherBSD, but anotherBSD would not give any other real
advantage - RedHat/*buntu would give much more useability than
OpenBSD/anotherBSD, but less security against realtime online attack against
a liveCD than anyBSD.

now we are left with two, OpenBSD and RedHat/*buntu Linux.


Thing is, would OpenBSD give enough security? - we would need it to be
secure, and could a say 5-year-old version of OpenBSD - even a well
tightened version, with eg no root account and only one or two open ports -
we would need it to be secure for at least another five years - with more
than the default install, ever be secure even against an online liveCD
attack? Not a single hole?




I doubt it. OpenBDSD's security model still sucks, and though it's getting
better it will never be 'there' as it is fundamentally broke. 4.4 was
designed in a morepleasant day (well ... notquite, if you could break all
the [passowrds they were virtually forced to give you a job :)

Note, I talked to some of the ~ Vista crew (JC-P) recently, and they are
doing the same old shit as OpenBSD does. It ain't personal.

He said Vista will be the second most secure (after OpenBSD) OS available. -
Ha! - but sadly, he's probably correct ... - (50,000 lines of code removed
just because they could cause buffer overflows - WHAT!!? - are there 50,000
buffer overflows in Windows if you know the source? ouch!!!



so we are left with a Linux/RedHat/*buntu (ok there are many other Linux
choices, but the *buntus seem the flavour of the day, are well suited to
today's hardware, (and already have a nice liveCD version :)


So a *buntu based m-o-o-t will be vulnerable to contemporaneous attack (as
it's a CD it won't be subject to eg most viruses, trojans, moles, worms or
online attacks after it's shut down and rebooted - we hope). Can we expect
to do any better?


If I used OpenBSD would it be any better?



[2] Window managers/desktop environments.

Windows, Darwin (well..), Gnome, KDE, xfce, fluxbox

I like *box. It's small, so will load quickly (very important for a liveCD
that people are encourged to use only occasionally when they want to do
something secure) - and they got the bars on the sides of the windows right,
same as Windows or MacOS, not like the usual *nixen bars. Nah, but ... :)



m-o-o-t - for when you want to do something secure -

- if you can't do it in m-o-o-t, then it probably can't be done securely -
if you can do it in m-o-o-t, in m-o-o-t it can _only_ be done securely :)

- or you _know_ any remaining risks, because they have been very forcibly
pointed out to you -



That's the idea anyway.






[3] Browser - no.

Note - that's a "Sort-of-no" - a https-only browser is a possibility. But a
browser that can access http sites is not going to be included in m-o-o-t.
Sorry.







[4] Messaging - secure (but traceable) messaging will be readily available.
An observer with total access to the 'net will be able to trace a message
sent this way from sender to recipient, but he won't be able to know the
content. We can, for regular correspondants, make it impossile o know when a
message was sent by using cover traffic. This might not seem suitable for
many purposes - but consider spam email. You probably get lots of that..




I also hope to have a different messaging solution available (unfortunately
paid-for, which will cost maybe £15 -£25 per year - the server costs are not
inconsiderable, and that may be an underestimate - but which will be
mathematically-from-traffic untraceable - whether you sent, or to whom you
sent, a message will be untraceable, only that you used the service).



For more ordinary requirements, I propose sharing OTP pads as a general
social mannerism. Meet, share a pad. Thing is, when you get an OTP pad from
someone it might be some random data, or it might be something else - but
you don't know.

The real trick now is that you don't store the OTP with any other data that
identifies it. It's just some stored data. No time stamp, no "last
modified", no nothing. Just some data.

Hey, this data might have come from him, or her, or her or .. - I simply
don't know where it came from. See, here is the software - and I don't, and
can't, know what this data is.




[5] stored data. Later I'm too drunk now :)
--
Peter Fairbrother



{a}I can imagine a system that would be secure, but it would probably need a
Harvard architecture (seperate program and data busses). Not really a
problem in a liveCD, but everyday hardware might not like that ..
Shane J Pearson
2006-10-21 06:06:30 UTC
Permalink
Post by Peter Fairbrother
[5] stored data. Later I'm too drunk now :)
Can't wait. Somehow I think this thing they call a "moment of
clarity" is highly over rated.


Shane J Pearson
shanejp netspace net au

Loading...