No subject

out the bios, even if password protection is set, since the kernel can
bypass and alter bios memory at will (previously I had assumed that the
bios could block updates via password, other than when power is cycled
during physical access).

> 
> > Some filesystems do support ACL's (access control lists) for extended
> > mandatory access, but that too is part of the kernel...if the kernel
> > does not want to honor it, it won't help.
> 
> And the distribution. I don't know if the current distributions
> include the userspace software for setting such configurations, or
> have capabilities built into their kernels.

ACL's are great for fine-grain control of security on a non-compromised
system. They also provide a way to further refine just who is given
access, which is a kind of security in itself, but I consider it totally
inadequate once the kernel itself has been replaced or altered.

> 
> > It seems that there is a need to arm the kernel with an absolute
> > shield section that out of single user mode cannot be modified or
> > viewed. Once you have that, the options increase dramatically.
> 
> Once you have that, root is no longer root. The other thing is, the
> purpose of the kernel is to provide services for userspace - if the
> kernel can't be configured at runtime, which is what an "absolute
> shield" would do, you couldn't use modules, couldn't use /proc, you
> couldn't set firewalling rules, you couldn't change the networking
> configuration, or use X, or use USB devices... or anything that would
> involve system calls... which, now that I think of it, would include
> any kind of I/O.  And *that* would make the computer entirely useless.
> On the other hand, your userspace programs couldn't interact with the
> kernel, and you'd have pretty effective security.  About as good as
> unplugging from the network.

It seems I inadequately described "absolute shield". I did not mean to
say the whole kernel, nor all of memory. What I did imply is that it
would be nice if, during single user stage, various portions of memory
could be altered to be readable and modifiable ONLY from the code that
runs and resides within that memory...what runs there could query and
observer outside areas. Thus it might be that you've mapped a 16 MB area
of ram that runs encryption independently, maybe doing nothing more than
verifying keys (but the idea is that the rest of the kernel behaves
normally). In a way I guess you could say it is inspired by Alpha cpu's
and other cpu's that can run simultaneous threads directly in the cpu,
almost like a single chip SMP system. Now if an area like this was the
hard disk driver, and requests could be sent to it, or if the area
monitored an outside request pool, you could still feed it garbage, but
it would have the right to refuse. Further, any attempt to write to it
directly should be 100% denied. This is what I mean by an absolute
shield on some small subset of ram. Modules and all else would work just
fine. Module loader code could be placed in such an area as well, so it
could hide what it does...no strace or other means could view its
internals, only its talking to the outside world could be snooped. Yes,
it would be just about impossible to do :(


> 
> > If this couldn't be done, perhaps there would be a way to
> > transparently do strong encryption of that block of memory, making
> > observation useless.
> 
> Again, the same old problem: it has to get decrypted somewhere. When
> it is, you're back to the same question I brought up before... where's
> the software that does the decryption, and where's the key stored to
> do it - both of which can be determined with a debugger.

That is another reason why there needs to be a truly "private" memory,
that can provide function interfaces, but cannot be snooped or examined
by anything once it passes beyond single user mode.

> 
> > With encrypted memory, there could still be problems with someone
> > modifying it;
> 
> Or corrupting, or decrypting.

I was thinking of corrupting, but more about complete replacement. Donor
memory overwrite.

> 
> > it would be interesting if cpu's came with hardware support of
> > mandatory memory encryption for specified blocks of ram.
> 
> That seems a rather intuitively difficult proposition.  I can't really
> explain why just now, since I'd like to sit back and dig through a
> book I have on the kernel and my old notes on assembly language, but
> I'm quite sure that this would be much more complicated than doing it
> in software.

Not really, even ethernet cards can be purchased with hardware for real
time encryption. The eepro100 has an "S" version, as one example. Plus
several of the wireless modem or network cards now have some form of
encryption that is hardware generated. It's already basic tech, just not
added to a cpu that I know of. I'd like to see it available hard wired
to x86. It could be provided its algo via flash memory, or even a
separate rom plugin chip. Physical access could defeat it, but I am only
talking about protection against people who have remote access.

> 
> The problems might be:
> 
> Where is the key and how does the CPU determine whether a given
> piece of code should be able to access it?

In ROM. Direct physical connection, similar to an encrypted ethernet
card (existing tech rearranged).

> 
> Can the encrypted area of memory be read or written to without the use
> of the encryption access functions (is it in main memory where
> programs or hardware devices could access and examine it)?

With current cpus, I doubt it could be forced to protect the area.
Integration of an encryption unit (think of EU like FPU) could be hard
wired such that once enabled, the area *cannot* be taken out of
encryption mode, nor could the algo it runs under be viewed by any means
(without reboot).

> 
> Is the algorithm hard-wired into the CPU?  If so, how could the
> algorithm be changed, if flaws are discovered or a different algorithm
> is needed?

Plugin ROM, or flash memory. There is no intent to even pretend to
protect a system that is physically accessible.

> 
> How would you handle sharing keys between processors on a
> multi-processor system?

I would suggest that each cpu would have to have the same keys stored in
each. Drop in the right ROM chip, voila.

> 
> Unencrypted data would need to be put somewhere once it's encrypted or
> decrypted in order to be used... how would you prevent access to it
> before encryption is performed, or after decryption is performed?

Regions of memory to be protected would be mapped in single user mode.
Any code or data inside that area would be initialized and started in
single user mode. Then a hardware pin would be asserted, and short of
reboot, *nothing* could do anything but use the existing functions and
interfaces of that memory block. What is outside of the block,
unencrypted, would not be protected. Anything that is generated from
inside the block would *never* be visible to the outside world, without
the block allowing it. In the case of a disk driver, for an encrypted
filesystem, this would do wonders.

> 
> How much more circuitry would be added to a CPU in order to facilitate
> this?  How would the demands of encryption affect pipelining and
> performance?

Don't know. But since the tech exists now for network cards, it should
be reasonable (as long as the economy wants it). Network cards and
wireless adapters with encryption slow down, I think that is
unavoidable. How much it slows would depend on how it is used and how
the hardware is designed.

> 
> How would you prevent access of encrypted data that's been swapped to
> disk?

The drivers themselves could be in an encrypted/protected segment of
memory. The reads/writes could enforce that everything going to the disk
is encrypted. The process of encrypting and decrypting would be private,
and inaccessible, as enforced by hardware. The trick is to (a) create
the hardware support for mapping areas of ram as enforced for access
blocking, (b) create the hardware to do encryption on-the-fly (or else
use software within the protected area), and (c) map your relevant
driver or other libraries into this area before asserting the pin that
says "you are now independent, nobody has authority over you but you".

> 
> I'm sure there's more problems, but these are things I'd want to know
> about any plan for including encryption on the CPU level.

I never said it would be easy. But it sounds like it is the next step in
the evolution of more "transparent" security that does not cripple
normal use. "Normal use" is critical, anyone can cut off the legs to
keep something from walking away.

D. Stimits, stimits at idcomm.com

> 
> Hmmm. Maybe I should get some sleep tonight.
> 
> --
> Chris Riddoch         |  epistemological  | Send spam to: uce at ftc.gov
> socket at peakpeak.com   |  humility         |
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug