[3685] in cryptography@c2.net mail archive
RE: Is a serial cable as good as thin air?
daemon@ATHENA.MIT.EDU (Ed Gerck)
Wed Dec 2 14:25:02 1998
Date: Wed, 2 Dec 1998 17:03:00 -0200 (EDT)
From: Ed Gerck <egerck@laser.cps.softex.br>
To: cryptography@c2.net
In-Reply-To: <199812020724.BAA00010@tecaprocorp.com>
On Wed, 2 Dec 1998, Dianelos Georgoudis wrote:
> [snip]
>
> Here I am not concerned about the security of our application
> itself, but rather whether our application can be used to attack
> the bank's private computer network and interfere with the bank's
> normal operation.
Dianelos:
That is probably the least risk, since your application is
well-behaved and will never attack the bank's computer as efficiently
as one that does not have all its internal checks and balances, and
task limitations. Further, attacks are not only limited to the bank's
computer, as one could also log all incoming decrypted traffic and
broadcast to somewhere else.
> On this network we plan to install a PC
> connected to the Internet server by a serial cable. A dedicated
> program on this PC will receive from the Internet server encrypted
> data packages. These packages will be decrypted with the
> individual clients' passwords,
you mean ... passwords?
> the resulting plaintext will be
> validated,
Plaintext cannot be securely validated. BTW, even perfect encryption
does not imply security (ie, tamperproof, origin authentication,
etc.) -- just privacy (ie, no eavesdropping).
> and if all looks right it will be forwarded and
> processed by the bank's internal system. All packages that do not
> validate correctly will be discarded. If three or so packages with
> the same client id fail to validate in a row, future packages with
> this id will be processed slowly.
>
You have just reinvented a firewall! But note that before decryption
you must somehow associate the decryption key with the user -- i.e.,
you must certify the user ... however, who is at the other side? Is
that key really from the user? Is the key still valid? Etc..
> Now, my reasoning is this: as I understand it, when a hacker
> attacks a network, he finds a way to access or modify files on
> this network, execute system level commands or plant his own code.
> As far as I can see this will be impossible in our set-up; an
> attacker will never be able to do anything worse than fake
> transactions of our own application and therefore the bank's risk
> cannot be higher than that.
>
However ... it can, like a firewall can also be attacked, subverted,
exploded in buffer-overflow, monitored, by-passed, etc.
> The serial connection will not be one-way.
I doubt it could.
> The networked PC will
> use the same cable to send (encrypted) confirmations to the
> clients and to update the (encrypted) data base on the Internet
> Server.
Of course, since they must all pass through the server.
> If the internal network itself cannot be compromised,
> neither is there any danger in having data sent out by our own
> program.
>
"If" is not granted either.
Hope to have helped,
Cheers,
Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br
http://novaware.cps.softex.br
