× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: E-Commerce Software Flaw Found
  • From: Mark Bauman <mlbauman@xxxxxxxxxxxx>
  • Date: Thu, 2 Jul 1998 15:08:24 -0500 (CDT)
  • In-Reply-To: <000501bda14a$ebec0f90$de62e20a@usnjrarpw01m0.telecom.ups.com>

Howdie Midrange! 

This is the first place I decided to post this message!   It discusses
the potential threat to AS/400 native SSL enabled servers from a PKCS #1
attack as detailed in the following information.  Anyone using the
limited availability PTF to obtain the SSL APIs should be reading this
information.   



RSA Data Security Inc. announced Friday, June 26th, on its website at
http://www.rsa.com, that there is a security exposure with protocols and
applications that use RSA PKCS#1 for key or data exchange.  SSL is one
such protocol.  To see more about the general IBM  response to this
exposure see URL  http://www.ibm.com/security/html/featrsaann.html.  To
see more about the technical announcement visit the RSA PKCS #1 webpage
at http://www.rsa.com/rsalabs/pkcs1/.   

Please note that this attack is theory - it has not been implemented by
anyone or successfully tested in an actual real life situation.   

AS/400 has analyzed the recently found potential threat to the  PKCS #1
based interactive key exchange used in the OS/400 native SSL
implementation.  Below is the result of that analysis, including a
discussion of the current counter measures that exist in the current
code, and the proposed additional counter measure implementation.    

The problem, as it relates to an SSL user, is as follows:  

1)  A hacker could record an SSL session between an interactive SSL
enabled client and server.   If the session was recorded over the
Internet,  the hacker would have to ensure that they filtered out all
other traffic other than the actual  SSL packets between a specific
client and a specific server.   

2) After recording the SSL session, the hacker could  extract handshake
messages from  within that recorded session and use the handshake
messages as a basis for construction of  carefully formatted messages to
be used to probe the server.   

3) The hacker would attempt to repeatedly establish  an SSL session
connection with the SSL enabled server using these carefully constructed
messages.  The response to each probe would need to  be carefully
analyzed and based on the server's response, each additional probe would
be adjusted accordingly.  Eventually, after approximately 1,000,000
probes, the hacker could break the encrypted handshake  message's PKCS
#1 digital envelope.      

4) Once the handshake message's digital envelope is broken, the hacker
could eventually  determine the read and write symmetric keys for that
particular, recorded SSL session and would be able to decode any 
encrypted data from that specific recorded SSL session.    

5) The hacker would only be able to recover data from a single session
per attack.  No other SSL session's data  could be decrypted unless the
hacker went thru all of the same steps for each SSL session.   

6) The private key of the server is not exposed or at risk by this
attack.       

7) This problem only affects the server implementations of SSL or server
applications built using SSL.  It does not affect client SSL code.  


There are counter measures for this type of attack.  See URL
http://www.rsa.com/rsalabs/pkcs1/prescriptions.html for details.   

Three of these counter measures relate directly to the code for any SSL
implementation.  OS/400 native SSL implements two of the three counter
measures in the original V4R1M0 and V4R2M0 native SSL server code. 
These two counter measures alone increases the number of messages
required to break the digital envelope of the handshake message from
1,000,000 message probes to over 20,000,000 message probes.    

Even though the risk from this attack to OS/400 SSL servers is  very
small (based on the fact that this attack has not actually been
implemented, and the fact that the original OS/400 native SSL code
already implements two of the three counter measures) we take this
potential attack very seriously.   Therefore,  the third counter measure
is currently being implemented for V4R1M0 and V4R2M0 releases.   PTFs
containing the updated SSL code with the third counter measure will be
made available soon.  Once the PTFs are completed and tested this
posting will be updated with their availability. 

Mark L. Bauman 
As/400 Communications Software Development  
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.