rronkko@csc.fi (01/07/91)
I would like to find an efficient and relatively cheap way to prevent
'unauthorized' use of my Amiga. Because there is no hardware-based locking
mechanism in A2000/A3000 itself, not even optional (BTW why, Commodore?!),
I have to find some other solution. I have been thinking about two tricks,
both of which are probably needed:
1) A 'special' diskette, which can be locked into the diskette drive
(I suppose the ones sold for PC:s can be used also in Amiga?). There is,
however, a couple of problems: IF the lock-diskette is non-bootable, then
the machine will boot from my autobooting Hard Disk, and the lock-diskette
is useless. On the other hand, IF the locking diskette is bootable, a
skilled 'unauthorized user' would eventually find his way to my auto-
mountable HD from the cli prompt, which he will reach with the Ctrl-D, even
if I use some password software on the lock-diskette.
So, my question is: Is there any way to make this lock-diskette to crash or
lock the machine BEFORE the startup-sequence is executed and the CLI prompt
is available with Ctrl-D?
2) Because it seems this Ctrl-D is a major problem here, what if the initial
keymap would not recognize the Ctrl-key... It is possible to edit the keymap
files located in the devs:keymaps, but where does the initial keymap (before
you use the setmap command to select your national keymap) come from? Is it
in the Kickstart rom? Would it be in that case possible to get a modified
Kickstart? And how about A3000, which has the 2.0 Kickstart still on HD...
Has anyone tried to make this kind of change him/herself?
Of course you need the Ctrl-key later, but if the first line of your startup-
sequence would be "Some-password-program-which-locks-your-machine" and the
second "Setmap normal-keymap", there should be no problems. But maybe there
is some good reason which prevents this kind of tricks...
---------------------------------------------------------------------------
Reijo Ronkko University of Helsinki, Dept. of General Microbiology,
Mannerheimintie 172, 00300 Helsinki, FINLAND
Fax +358-0-4735426
Ronkko@cc.helsinki.fi
---------------------------------------------------------------------------ifarqhar@sunc.mqcc.mq.oz.au (Ian Farquhar) (01/07/91)
Actually, there may be a solution to this that would be reasonably
secure, though it isn't pretty. Write a handler that sits between the
l:fastfilesystem handler and the dos.library (ie. handler entry in the
devs:mountlist points to your handler and your handler loads the
l:fastfilesystem handler), which encodes all data going to and coming
from the disk.
The hardest is encoding the data. You have to decide two things:
1) What to encode. You could only encode the data going to and coming
from the read and write packets, so that the directory structure
looked fine, but the data in these files was encrypted. Or you
could encode everything, which is less safe (as recovering corrupted
data would become a real pain) but more secure.
2) How to encode. The ideal method would be a one-time pad, but this
is a little difficult to arrange :-) DES is an option, but it is
notoriously slow to implement in software. I would tend to go for
a multi-barrel 256-slot enigma machine, which is fast to implement
in assembler (it's all tables and pointers), and reasonably secure.
If you had an 8 character password, this would yield 56 usable bits
(in 7 bit ASCII), which would mean that it could set up to seven
256 slot barrels. That is not going to stop the NSA, but it will
put Joe Average right off.
The password, of course, is established when the handler is fired up.
This could be done by a floppy (not advised, as it would contain the
barrel tables which would not necessarily compromise the encryption, but
make it somewhat easier to break), or much better to have it on a hard
disk partition in the old filing system, from which the secure one
boots.
Comments, anyone? A small point: the file comment field makes the ideal
place to store security information if you wanted to extend this
further.
--
Ian Farquhar Phone : 61 2 805-9400
Office of Computing Services Fax : 61 2 805-7433
Macquarie University NSW 2109 Also : 61 2 805-7420
Australia EMail : ifarqhar@suna.mqcc.mq.oz.aumt87692@tut.fi (Mikko Tsokkinen) (01/07/91)
If you want to prevent others for using your amiga you can for example do following: - buy diskdrive lock (you can't take off or enter any disks) - write a bootblock which asks for password This is at least one solution, I don't know better. MIT -- Bubble Bobble
x194@cs.utexas.edu (Jonathan Abbey) (01/08/91)
In article <1991Jan6.233133.1@csc.fi> rronkko@csc.fi writes: >I would like to find an efficient and relatively cheap way to prevent >'unauthorized' use of my Amiga. Because there is no hardware-based locking >mechanism in A2000/A3000 itself, not even optional (BTW why, Commodore?!), >I have to find some other solution. I have been thinking about two tricks, >both of which are probably needed: > >1) A 'special' diskette, which can be locked into the diskette drive >(I suppose the ones sold for PC:s can be used also in Amiga?). There is, >however, a couple of problems: IF the lock-diskette is non-bootable, then >the machine will boot from my autobooting Hard Disk, and the lock-diskette >is useless. On the other hand, IF the locking diskette is bootable, a >skilled 'unauthorized user' would eventually find his way to my auto- >mountable HD from the cli prompt, which he will reach with the Ctrl-D, even >if I use some password software on the lock-diskette. If what you want to do is prevent anyone from using your amiga, you could concoct a custom boot block for your harddrive that requires the user to enter a password to continue using the system. This, combined with a lock diskette for your internal drive, would effectively lock out any unauthorized users. Such a thing may already exist out in the big world some place. If not, it should be the matter of an afternoon for a good assembly programmer. It sounds like what you really want to do, though, is prevent unauthorized access to your harddrive. For this, you could use the lock command to lock your partitions. I seem to recall that this is only effective until a reboot, and so not helpful. You could, if truly desperate, patch the internal scsi cable, so that the line used to recognize your internal hard drive (I'm simply assuming there is such a thing, mind you) is brought out to a key switch. The power line for the hard drive could be brought out in any case, and this could be the simplest solution. If you want to get really fancy, you could build a credit-card security switch. The March 1983 _80 Mirco_ has plans for it. If you do go for a switch, Radio Shack has plastic boxes you could install it in, rather than marring your computer's case. Good luck. ------------------------------------------------------------------------------- Jonathan Abbey The University of Texas at Austin x194@cs.utexas.edu Computer Science --
peterk@cbmger.UUCP (Peter Kittel GERMANY) (01/08/91)
In article <1991Jan6.233133.1@csc.fi> rronkko@csc.fi writes: > >1) A 'special' diskette, which can be locked into the diskette drive >(I suppose the ones sold for PC:s can be used also in Amiga?). There is, >however, a couple of problems: IF the lock-diskette is non-bootable, then >the machine will boot from my autobooting Hard Disk, and the lock-diskette >is useless. On the other hand, IF the locking diskette is bootable, a >skilled 'unauthorized user' would eventually find his way to my auto- >mountable HD from the cli prompt, which he will reach with the Ctrl-D, even >if I use some password software on the lock-diskette. > >So, my question is: Is there any way to make this lock-diskette to crash or >lock the machine BEFORE the startup-sequence is executed and the CLI prompt >is available with Ctrl-D? There should be a way: Modify the little program that is in the bootblock of an INSTALLed disk. I didn't try this, but how about changing that finishing JMP (or ist it JSR?) to BRA to itself, running an infinite loop? (I fear you also would have to adjust a checksum on that block.) But the other problem with this is that I don't believe you can get lock-diskettes with real media in them. The only ones I know can't be used for two reasons: a) they are solid plastic plus a little metal; b) they fit mechanically only into IBM PS/2 drives. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
jdickson@jato.jpl.nasa.gov (Jeff Dickson) (01/09/91)
In article <1025@macuni.mqcc.mq.oz> ifarqhar@sunc.mqcc.mq.oz.au (Ian Farquhar) writes: >Actually, there may be a solution to this that would be reasonably >secure, though it isn't pretty. Write a handler that sits between the >l:fastfilesystem handler and the dos.library (ie. handler entry in the >devs:mountlist points to your handler and your handler loads the >l:fastfilesystem handler), which encodes all data going to and coming >from the disk. > >The hardest is encoding the data. You have to decide two things: > >1) What to encode. You could only encode the data going to and coming > from the read and write packets, so that the directory structure > looked fine, but the data in these files was encrypted. Or you > could encode everything, which is less safe (as recovering corrupted > data would become a real pain) but more secure. > >2) How to encode. The ideal method would be a one-time pad, but this > is a little difficult to arrange :-) DES is an option, but it is > notoriously slow to implement in software. I would tend to go for > a multi-barrel 256-slot enigma machine, which is fast to implement > in assembler (it's all tables and pointers), and reasonably secure. > If you had an 8 character password, this would yield 56 usable bits > (in 7 bit ASCII), which would mean that it could set up to seven > 256 slot barrels. That is not going to stop the NSA, but it will > put Joe Average right off. > >The password, of course, is established when the handler is fired up. >This could be done by a floppy (not advised, as it would contain the >barrel tables which would not necessarily compromise the encryption, but >make it somewhat easier to break), or much better to have it on a hard >disk partition in the old filing system, from which the secure one >boots. > >Comments, anyone? A small point: the file comment field makes the ideal >place to store security information if you wanted to extend this >further. > >-- >Ian Farquhar Phone : 61 2 805-9400 >Office of Computing Services Fax : 61 2 805-7433 >Macquarie University NSW 2109 Also : 61 2 805-7420 >Australia EMail : ifarqhar@suna.mqcc.mq.oz.au Newsgroups: comp.sys.amiga.tech Subject: Re: How to LOCK your Amiga? Summary: Expires: References: <1991Jan6.233133.1@csc.fi> <1025@macuni.mqcc.mq.oz> Sender: Reply-To: jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) Followup-To: Distribution: Organization: Jet Propulsion Laboratory, Pasadena, CA Keywords: In article <1025@macuni.mqcc.mq.oz> ifarqhar@sunc.mqcc.mq.oz.au (Ian Farquhar) writes: >Actually, there may be a solution to this that would be reasonably >secure, though it isn't pretty. Write a handler that sits between the >l:fastfilesystem handler and the dos.library (ie. handler entry in the >devs:mountlist points to your handler and your handler loads the >l:fastfilesystem handler), which encodes all data going to and coming >from the disk. > >The hardest is encoding the data. You have to decide two things: > >1) What to encode. You could only encode the data going to and coming > from the read and write packets, so that the directory structure > looked fine, but the data in these files was encrypted. Or you > could encode everything, which is less safe (as recovering corrupted > data would become a real pain) but more secure. > >2) How to encode. The ideal method would be a one-time pad, but this > is a little difficult to arrange :-) DES is an option, but it is > notoriously slow to implement in software. I would tend to go for > a multi-barrel 256-slot enigma machine, which is fast to implement > in assembler (it's all tables and pointers), and reasonably secure. > If you had an 8 character password, this would yield 56 usable bits > (in 7 bit ASCII), which would mean that it could set up to seven > 256 slot barrels. That is not going to stop the NSA, but it will > put Joe Average right off. > >The password, of course, is established when the handler is fired up. >This could be done by a floppy (not advised, as it would contain the >barrel tables which would not necessarily compromise the encryption, but >make it somewhat easier to break), or much better to have it on a hard >disk partition in the old filing system, from which the secure one >boots. > >Comments, anyone? A small point: the file comment field makes the ideal >place to store security information if you wanted to extend this >further. > >-- >Ian Farquhar Phone : 61 2 805-9400 >Office of Computing Services Fax : 61 2 805-7433 >Macquarie University NSW 2109 Also : 61 2 805-7420 >Australia EMail : ifarqhar@suna.mqcc.mq.oz.au The problem with having an additional channel for disk data is that it greatly slows the system. Why not request an exclusive write lock on the root of the filing system. Others users could use your stuff, but they couldn't overwrite or delete it and that's what you're after - right? Jeff
mfontana@blumax.UUCP (Mike Fontana) (01/09/91)
--
Why not use a hardware fix?
Purchase an ignition type switch with a key and replace your on/off switch
with it.
(Personal responses should be by email; I don't always get USENET postings.)
SEND EMail To: mfontana%blumax.UUCP@uhasun.hartford.edu
----------------------------------------------------------------------------
\\ // |) | | | | | /_\ \/
\XX/ |) |_ |_| |\/| | | /\
I used to be indecisive, but now I'm not so sure.
----------------------------------------------------------------------------