Re: Is a serial cable as good as thin air?
> static uint16 mul(register uint16 a, register uint16 b)
> {
> register word32 p;
>
> p = (word32) a *b;
> if (p) {
> b = low16(p);
> a = p >> 16;
> return (b - a) + (b < a);
> } else if (a) {
> return 1 - a;
> } else {
> return 1 - b;
> }
> } /* mul */
> There was some discussion of approaches to coding a constant time
> multiplication mod 65537 function on sci.crypt around October 96.
Note that on many microprocessors multiply is not a constant-time instruction,
leading to difficulties.
However, in more recent code there are two alternatives:
An optimized version of the above:
{
register PGPUInt32 p;
p = (uint32)a * b;
if (p) {
b = low16(p);
a = p>>16;
return (b - a) + (b < a);
} else {
return 1-a-b;
}
}
and the AVOID_JUMPS case, which is constant-time if the multiply is
(it's also faster on some processors):
{
register word32 p;
a = low16(a-1);
b = low16(b-1);
p = (uint32)a*b + a + b;
a = low16(p);
b = p >> 16;
return (a - b) + (a < b) + 1;
}
The only potential gotcha is the "a < b" part, which compilers
usually find branch-free code for, but sometimes they're dumb.
--
-Colin
Re: Is a serial cable as good as thin air?
David Conrad writes:
> On Wed, 2 Dec 1998, Dianelos Georgoudis wrote:
> > I will include a random delay to invalidate timing attacks.
>
> The right solution is to ensure that all encryptions, decryptions,
> signings, or signature verifications take the same amount of time.
> (The maximum, worst case time.)
For RSA there is also the approach of using blinding which Ron Rivest
proposed.
> Of course, this applies (as I understand it; see parenthetical disclaimer
> above) only to public key operations.
John Kelsey found a timing attack on IDEA also, so not necessarily.
Probably you are correct for most block ciphers but IDEA includes mod
65537 code encoded in 16 bit shorts by using the 0 value to represent
65536, which typically involves tests for values which need special
treatment. Here's the relevant bit out of pgp2.x:
static uint16 mul(register uint16 a, register uint16 b)
{
register word32 p;
p = (word32) a *b;
if (p) {
b = low16(p);
a = p >> 16;
return (b - a) + (b < a);
} else if (a) {
return 1 - a;
} else {
return 1 - b;
}
} /* mul */
There was some discussion of approaches to coding a constant time
multiplication mod 65537 function on sci.crypt around October 96.
Adam
RE: Is a serial cable as good as thin air?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 2 Dec 1998, Dianelos Georgoudis wrote: > I will include a random delay to invalidate timing attacks. Timing attacks work by collecting data over a large number of trials. Over a large number of trials, a random delay approximates the mean delay and can be subtracted out. (This is a rough description from someone who has never implemented a timing attack.) Random delays only add a (small) layer of complexity, and do not invalidate timing attacks. The right solution is to ensure that all encryptions, decryptions, signings, or signature verifications take the same amount of time. (The maximum, worst case time.) Of course, this applies (as I understand it; see parenthetical disclaimer above) only to public key operations. It sounds as if you are doing symmetric encryption and database access, so this may not even be a concern for you. But if you're using RSA, DSS, Elliptic Curve, or the like, then it's something you need to think about. David R. Conrad <[EMAIL PROTECTED]> "On two occasions I have been asked [by members of Parliament!], `Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question." -- Charles Babbage -BEGIN PGP SIGNATURE- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQA/AwUBNmbooIPOYu8Zk+GuEQKthgCfQsOxmFoY68kZgLXwBf3WT/fVJ8EAn0dk HVyzKBSi1GtuPycaoYmFvb2P =/ztI -END PGP SIGNATURE-
Re: Is a serial cable as good as thin air?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The original poster mentioned that the secure host would verify that all data coming in over the serial connection was in the proper format. Thus it is being contemplated that an attacker could compromise the outer host and send arbitrary data to the secure host. An attacker might not try to send packets of entirely forged data, but merely, say, add a single byte to each packet transmitted. This would cause all packets of data to fail the format test, and would constitute a denial of service attack. Since I'm sure you'll be logging any invalid packets received (modulo error detection/correction?) and studying them carefully, there should be no difficulty detecting such a condition. David R. Conrad <[EMAIL PROTECTED]> "On two occasions I have been asked [by members of Parliament!], `Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question." -- Charles Babbage -BEGIN PGP SIGNATURE- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQA/AwUBNmbliYPOYu8Zk+GuEQLd4ACeK55J5T8IxAXOECr7YYY6wuEDYzAAnjAw DI3yAkEM55/Tnym5yeZ4oc0T =NLum -END PGP SIGNATURE-
Re: Is a serial cable as good as thin air?
The problem is that we're trying to combine the answers to two rather separate questions. > Here is the question: Is this as good as thin air? With suitable precautions as discussed already, most likely yes. > Can you see any way a hacker could use such a connection to penetrate > the bank's network? Sure, but you can do that with floppies, too, as also discussed. I think the real answer is "restate the question, please." Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://iecc.com/johnl, Sewer Commissioner Finger for PGP key, f'print = 3A 5B D0 3F D9 A0 6A A4 2D AC 1E 9E A6 36 A3 47
RE: Is a serial cable as good as thin air?
At 1:24 AM -0600 12/2/98, Dianelos Georgoudis wrote: >Thank you all for the feedback; I will take your observations into >account - replay attacks are accounted for and, for good measure, >I will include a random delay to invalidate timing attacks. I see >now that I should have been somehow more specific with my original >question: Having more information certainly helps, but I still feel a more fromal analysis is required to assert security at either an absolute or relative level. Potential weaknesses are always fair game, however! :) With that in mind: 1. I am very concerned about the statement your data is encrypted "with the individual clients' passwords." Typical user passwords and PIN numbers do not have anyway near enough entropy to serve as encryption keys for symetric ciphers, even if hashed with a standard algorithm such as SHA or MD5. Such keys can be broken in a matter of seconds on a PC. If that is what your application is doing, the data on your server should not be considered encrypted and must be treated as fully open to the hackers. 2. Rebuilding the server periodically (maybe every night) would be good, as would removing all source code and development tools. But for the purpose of this kind of analysis, you must assume that a hacker can get complete root-level control of your Internet server. 3. You need to consider how you will insure and verify the integrety of the PC. If the PC is connected to the bank internal network and the hacker can get his code into the PC, you are potentially vulnerable. Hackers are very good at "social engineering." Who will clean the office where this PC is located? Hope this helps, Arnold Reinhold
RE: Is a serial cable as good as thin air?
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 [EMAIL PROTECTED] http://novaware.cps.softex.br
RE: Is a serial cable as good as thin air?
Thank you all for the feedback; I will take your observations into account - replay attacks are accounted for and, for good measure, I will include a random delay to invalidate timing attacks. I see now that I should have been somehow more specific with my original question: Our home banking applications let the client use public Internet to access information about his accounts and allow for limited off-line transactional capability, such us to debit this account to pay that credit card. Encryption and decryption are implemented on the client's computer and within the bank's network. The Internet server is used only as a encrypted data repository and as a communications link. Now we want to implement on-line transactional capability. 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. 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, the resulting plaintext will be validated, 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. 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. The serial connection will not be one-way. 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. If the internal network itself cannot be compromised, neither is there any danger in having data sent out by our own program. Dianelos Georgoudis email: [EMAIL PROTECTED] http://www.tecapro.com
Re: Is a serial cable as good as thin air?
Let's look at the original question as written -- > Here is the question: Is this as good as thin air? Can you > see any way a hacker could use such a connection to penetrate the > bank's network? So we have 2 scenarios: (a) two computers connected by a serial cable; and (b) two computers capable of exchanging data only by 'sneakernet'. Very simply, the former provides an inherently general-purpose, always-up data link between the two machines, while the latter only provides the periodic transfer of data in small chunks. While bogus transaction data (i.e., in proper format) might be transmitted over either medium, (a) is much more flexible -- hence, more likely to be used for a nonintended purpose. Enforcing the protocol on the line is the obvious defence against this. Even if the external host were compromised, the internal host's custom serial software, if well-written, would only know how to deal with transaction data, everything else would be logged and cause an alarm condition. I think that for a vanilla serial cable, a lot rests on 3 factors: (a) the robustness of the software doing the communication, from hardware drivers, all the way up to the transaction protocol -- e.g., no buffer overruns, no insertion attacks; (b) aside from the serial port, the security of the internal host; (c) the physical security of the facility containing the hosts. If all 3 of these security factors are beyond question, then YES a plain old serial cable is as good as thin air. Otherwise, NO -- the cable could end up at the mercy of software on two compromised hosts, or perhaps a laptop and some splicing tools. Here comes file transfer and remote login to the internal host, via a convenient external gateway In this case, something more is needed to enforce the protocol on the line. Mr. Nelson recommended a hardware enforcing unidirectional Xmodem for the "paranoid" -- but if one of the factors mentioned above is a weak link in the chain, hardware must be the only option. Furthermore, if physical security is a concern, said hardware should be tamper-resistant, as should its physical connections to the 2 hosts. Hope this helps. Cheers, -- Stephen D. James <[EMAIL PROTECTED]> Research Scientist and Engineer POC Systems
(Fwd) Re: Is a serial cable as good as thin air?
From: Russell Nelson <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] Subject: Re: Is a serial cable as good as thin air? >Arnold G. Reinhold writes: > > I am uncomfortable with the tone of this thread. There is nowhere near > > enough information provided in Mr. Georgoudis' posting to conclude that > > hisbank's existing floppy disk transfer scheme is secure, much less render > > an opinion on the impact of a serial connection. Russell Nelson responds: >He didn't ask if it was secure. He only wanted to know if a serial >connection could be made as secure as a floppy disk transfer. I >contend that an xmodem transfer of the file is as secure as a floppy >disk transfer. The truly paranoid would insert a PIC chip which >enforces that only the xmodem protocol could transit the wire, and >then in only one direction. >Sure, the floppy disk transfer could be insecure, but as you say, he >neither gave us enough information, nor asked if we felt it was >secure. I think we need to revisit the original problem: can a serial-wire transfer protocol be implemented that protects the bank's computer from providing unlimited access. The simple answer is 'yes' - but it will require some modifications to the bank's software. First, the serial port must be isolated from existing drivers so that you can ensure that the port cannot be hijacked through whatever means. Then, the new driver must provide very specific services with appropriate protocol added to ensure that the data coming in the port is real -- you guys with more crypto experience can devise that scheme probably better than I can. Once you have written the driver with appropriate authentication and security protocols, and limited its range of action to processing only one type of transaction (updates from the remote terminal), the ability of an intruder to access any other data on the system is removed. Of course the connection must be 2-way because the protocol must provide for feedback to ask for resend of bad blocks, and commands to send the data must be implemented. But the driver can clearly be made to receive data only - never to send anything except commands and acknowledgments. Xmodem would work (Ymodem and Zmodem would probably be a bit better simply because they are faster), but it still would need a protocol of some sort added to specify what data to transfer, and perhaps to update keys or purge old data, etc. Were I coding the system, I think I would implement a custom protocol for everything and avoid something like Xmodem simply because I don't like the flow-control baggage you get with them. Such a package is relatively simple to implement, and can be made as robust as your requirements demand. Carl Carter - Software Eng Sansearch, Inc. [EMAIL PROTECTED] 10225 Willow Creek Rd voice(619) 635-5300 San Diego, CA 92131 fax(619) 635-5299
Re: Is a serial cable as good as thin air?
Arnold G. Reinhold wrote: > > I am uncomfortable with the tone of this thread. There is nowhere near > enough information provided in Mr. Georgoudis' posting to conclude that > hisbank's existing floppy disk transfer scheme is secure, much less render > an opinion on the impact of a serial connection. > Is each diskette examined before it is read in and cleaned before it is reused using an isolated system? I've seen sneakernet get pretty sloppy. Simple viruses can be spread rather quickly. Data that should have been erased can be left on tmp disks for months. The security of the "air-wall" could well be illusory. Especially with a little insider help in getting the infections and the subsequent two way "wireless" conversation going. Mix a few writes with the reads on the internal system, have the external system forward incoming packets and check for "outgoing packets"...could be a fun project.
Re: Is a serial cable as good as thin air?
Arnold G. Reinhold writes: > I am uncomfortable with the tone of this thread. There is nowhere near > enough information provided in Mr. Georgoudis' posting to conclude that > hisbank's existing floppy disk transfer scheme is secure, much less render > an opinion on the impact of a serial connection. > >:all). Here is the question: Is this as good as thin air? He didn't ask if it was secure. He only wanted to know if a serial connection could be made as secure as a floppy disk transfer. I contend that an xmodem transfer of the file is as secure as a floppy disk transfer. The truly paranoid would insert a PIC chip which enforces that only the xmodem protocol could transit the wire, and then in only one direction. Sure, the floppy disk transfer could be insecure, but as you say, he neither gave us enough information, nor asked if we felt it was secure. -- -russ nelson <[EMAIL PROTECTED]> http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | There is good evidence 521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace.
Re: Is a serial cable as good as thin air?
re. the use of a serial cable rather than an air gap / sneaker net (floppy disk). One thing that occurs is that if you were not careful the system might be used to mount a timing attack against the back-end machine. See Paul Kocher's RSA timing attack. Timing attacks may be possible without compromising the front end machine, the a compromised front end machine might have advantages in avoiding detection, or obtaining more accurate timing information. Adam
Re: Is a serial cable as good as thin air?
I am uncomfortable with the tone of this thread. There is nowhere near enough information provided in Mr. Georgoudis' posting to conclude that hisbank's existing floppy disk transfer scheme is secure, much less render an opinion on the impact of a serial connection. Most computer systems can be broken down in to a series of components, like links on a chain, and analyzed individually. If all the links are ok, the system should work. Cryptography is not like that. Crypto is more like a condom where a single hole can cause a failure without the user even being aware of the problem until it is too late. A careful analysis of Mr. Georgoudis' total system, including threat models, acceptable levels of risk, audit possibilities, etc. is needed to reach a sound conclusion. Arnold Reinhold At 1:46 PM -0600 11/30/98, Missouri FreeNet Administration wrote: >Why not keep the "ThinAir" concept, and use an optically-isolated link? >A one-way connection: just like your floppies... > >On Sun, 29 Nov 1998, Dianelos Georgoudis wrote: > >:Date: Sun, 29 Nov 1998 22:20:29 -0600 >:From: Dianelos Georgoudis <[EMAIL PROTECTED]> >:To: [EMAIL PROTECTED] >:Subject: Is a serial cable as good as thin air? >: >: >:We are installing home banking systems where the Internet Server >:is separated from the bank's computer center by air. Data is moved >:periodically back and forth using low tech but dependable floppy >:disks that carry only encrypted data (the principle of red/black >:separation is implemented by loading only encrypted data on the >:server). This "air-wall" is an effective way to stop hackers from >:penetrating the bank's computer center using its Internet >:services. This works quite well with services such as users' >:credit-card queries. >: >:Now, we have a potential client insisting on on-line transaction >:capability. One possible solution is to connect the Internet >:server with a PC on the bank's private network using a serial >:cable. We would write our own transmission protocol. The PC >:working on the bank's network would run a memory resident program >:that services the serial port and will discard any blocks that do >:not decrypt properly or have an invalid structure (only blocks >:that decrypt into the correct data structure would be processed at >:all). Here is the question: Is this as good as thin air? Can you >:see any way a hacker could use such a connection to penetrate the >:bank's network? >: >: >:Dianelos Georgoudis >:email: [EMAIL PROTECTED] >:http://www.tecapro.com >: >: > >Yours, >J.A. Terranson >[EMAIL PROTECTED] >[EMAIL PROTECTED] > >-- >If the Government wants us to behave, >they should set a better example!
Re: Is a serial cable as good as thin air?
Why not keep the "ThinAir" concept, and use an optically-isolated link? A one-way connection: just like your floppies... On Sun, 29 Nov 1998, Dianelos Georgoudis wrote: :Date: Sun, 29 Nov 1998 22:20:29 -0600 :From: Dianelos Georgoudis <[EMAIL PROTECTED]> :To: [EMAIL PROTECTED] :Subject: Is a serial cable as good as thin air? : : :We are installing home banking systems where the Internet Server :is separated from the bank's computer center by air. Data is moved :periodically back and forth using low tech but dependable floppy :disks that carry only encrypted data (the principle of red/black :separation is implemented by loading only encrypted data on the :server). This "air-wall" is an effective way to stop hackers from :penetrating the bank's computer center using its Internet :services. This works quite well with services such as users' :credit-card queries. : :Now, we have a potential client insisting on on-line transaction :capability. One possible solution is to connect the Internet :server with a PC on the bank's private network using a serial :cable. We would write our own transmission protocol. The PC :working on the bank's network would run a memory resident program :that services the serial port and will discard any blocks that do :not decrypt properly or have an invalid structure (only blocks :that decrypt into the correct data structure would be processed at :all). Here is the question: Is this as good as thin air? Can you :see any way a hacker could use such a connection to penetrate the :bank's network? : : :Dianelos Georgoudis :email: [EMAIL PROTECTED] :http://www.tecapro.com : : Yours, J.A. Terranson [EMAIL PROTECTED] [EMAIL PROTECTED] -- If the Government wants us to behave, they should set a better example!
RE: Is a serial cable as good as thin air?
Brown, R Ken writes: > If I was a bank I would be very wary of proposals like "We would write our > own transmission protocol. " That seems to introduce yet more complexity, > not to mention maintenance effort and undiscovered bugs. It would seem safer > (more conservative a bank might say) to use off-the-shelf code which had > been tried and tested (& for which source code was available if you really > cared about security) Use xmodem. Only provide the receive code and the transmission code on the respective sides. That will be as safe as sneakernet. -- -russ nelson <[EMAIL PROTECTED]> http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | There is good evidence 521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace.
RE: Is a serial cable as good as thin air?
> Dianelos Georgoudis[SMTP:[EMAIL PROTECTED]] described a security system > and then asked: > > Here is the question: Is this as good as thin air? The answer has to be "no" because you are introducing extra complexity. There is more to go wrong. > Can yousee any way a hacker could use such a connection > to penetrate thebank's network? No, but that doesn't mean *they* can't :-) Presumably you are talking about a situation where instructions posted on the web server from home users cause changes to be made in their accounts? In whioch case if the web server is compromised it could in principle be used to issue false instructions that conform to the expected format, however they were transmitted serial cable or floppy disk. If I was a bank I would be very wary of proposals like "We would write our own transmission protocol. " That seems to introduce yet more complexity, not to mention maintenance effort and undiscovered bugs. It would seem safer (more conservative a bank might say) to use off-the-shelf code which had been tried and tested (& for which source code was available if you really cared about security)
