Iain Shigeoka wrote:
> Very interesting. Can you elaborate or is there a wiki article on how
> jos could be used to create such a private computing environment? I
> think I know what you're talking about but can't be sure.
Unfortunately I have not created a Wiki page as I do not have the time
to maintain it. I will, though, try to elaborate a little:
1) The system part should be different from the administration part
which should be different from the user part. This means that there are
a few things that only the system can do, such as create security
sandboxes, flag code as privileged, have direct access to memory, etc.
The administration part can set security policies and run processes that
stay alive after a user has logged off. The users can only play around
with their own stuff, even if that is code being executed inside the
same VM as the system code (which is an obvious case in JOS).
2) All communication through any port must support various levels of
security, such as having the JOS system start with a pre-defined local
proxy server and firewall, so administrators and users can set their
incoming *and* outgoing policies for all ports of communication.
3) Encryption should not be facilitated by third party software, but
should be an integral part of JOS, at, say, filesystem level. Each user
follows an authentication method based on PKI, and disks are encrypted
with conventional encryption based on each user's preferences.
A basic idea is this:
Each user has a user id (string) and a password (string-hashed). The
system also stores a UID (string) and a system UID (string). It also
generates a temporary ID called, say, temporary (string). Authentication
is like this:
LOGON
Gather credentials:
password + user-uid + user-name + system-uid + temporary
Use credentials to create PBE cipher for DESede.
Use cipher to decrypt user's private DH/DSS key.
Create PKI cipher with private DH/DSS key.
Use cipher to decrypt user's symmetric DESede key.
Use symmetric DESede key to decrypt user's profile information.
Begin session.
LOGOFF
Encrypt user's profile directory with symmetric key.
Create new temporary UID and write to disk.
Gather credentials from memory but with updated temporary UID.
Create symmetric DESede cipher with above via PBE.
Encrypt with above cipher the private DH/DSS key.
Store encrypted private key to disk.
Empty stored credentials, private and symmetric keys from memory.
End session.
As you can see, this way eliminates the danger of others brute forcing
into the system (PKI can be DSS 4096 bits and symmetric can be DESede
128 bit), nobody can recover with private key without knowledge of
password.
If user uses the same password in many accounts throughout the Internet,
the system UID and the user UID will obfuscate the hash.
Also, the temporary UID which is random will give an attacker as much
time to brute force as the user needs to log in again. A new encryption
key is generated upon the termination of each session, which would mean
nobody would even think of starting a brute force attack.
Even if the user's password was compromised, there is still a little
safety, as the only way to obtain the system UID and the temporary UID
is by having physical access to the JOS box (assuming a Java VM or VM
with no pointers).
Temporary UID's will be generated by very good sources of entropy, too,
as nobody will know when the user terminates his session, nor the
parameters of the entropy sources at that instant. Deleting old keys and
the UID's by wiping them multiple times helps prevent their recovery and
statistical attacks on the system. The private key is re-written to disk
in enciphered state every time the user logs off, so recovery even by
means of physical access should be impossible. Otherwise the private key
remains *ONLY* in JOS memory space with absolutely no access to anything
but the system security module. Let's say these private keys are only
for decrypting the symmetric key used to protect the user's files, then
it can be generated by the system, and the user won't even have access
to it, which enhances its security. And since the user can't use it
outside of the specific JOS box, no clear text attacks can be performed.
There you go.
Don't you think the above system is quite protective for most users?
Please let me stress the word "users" as I cannot speak for truly strong
security without having an implementation of JOS to play around with.
Yet.
--
"Though this be madness, yet there is method in't."
- William Shakespeare
________________________________________________________________________
[MAIL: mailto:[EMAIL PROTECTED]] [URL: http://www.outworld.org/people/al/]
[TEL1: (30) +31 422392] [TEL2: (30) +31 428154] [CELL: (30) +937 110247]
[ICQ#: 11876955] [DSS: 0xDBEF8ECC] [RSA: 0xBC469499] [TIME: GMT +2.00 H]
[ADDRESS: 14 Argonafton St., Kalamaria, 551 31, Thessaloniki, Greece GR]
DO NOT SEND ME ANY UNSOLICITED COMMERCIAL, POLITICAL OR RELIGIOUS E-MAIL
_______________________________________________
General maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/general
