Re: Internet Security

[Dave Darnell <dave_d@xxxxxxxxxxxxx>]

At 11:18 AM 5/21/96 -0400, Dale Rickards wrote:
>Hi there,
>
>I have been reading your e:mail discussions over the last month and I
>thought it was time to express my views.
>
>MY BACKGROUND....
>
>I am female ... even though my name is Dale.
>

NO PROBLEM HERE!

>I worked for Sterling Commerce (formally Sterling Software) developing EDI
>data security software for 4 years and have implemented both the X12.58 and
>the X12.42 (version 3040 - prior to public key)  standards defined by ANSI
>X12.  I have also been part of the work groups developing these standards
>"X12-C committee Task group 6 - Data Security" and have been involved with
>the public key changes made to the standards  ((just a note - I have
>recently changed jobs but I am still active in data security))
>
>I have also worked with IBM to interface their black-box security solution
>into Sterlings EDI security software to provide a greater level of security.
>
>During this time I worked closely with the banks in the U.S. to implement
>security solutions for EDI.
>

Excellent background.  You are certainly qualified to post here.


>E:MAIL VS EDI....  
>
>I don't think that you can come up with the same solution for both E:Mail
>(or other internet information) and EDI.  
>
>EDI is exchanged between trading partners who have a trading partner
>agreement and have identified what type of relationship they will have.
>They have defined the transaction sets they will be exchanging and which
>segments and elements they will be using.  When they use security, they will
>still have a trading partner agreement which defines the relationship.
>Banks are the only organizations who seem to be implementing EDI security
>(although other companies are discussing it because the banks are forcing
>them to).  The banks usually have a security officer who sets up security
>ID's and defines key values (DES) and exchanges them with their trading
>partners.  This will not change when using public key no matter which
>algorithm they use because banks tend to be security nuts (for good reason).
>This means that  the algorithm that EDI, sent though the internet, uses
>should be flexible so that way these trading partners can choose the
>algorithm that they feel comfortable with (ie. RSA, PGP etc).   The X12.58

PGP is not an algorithm - it currently uses RSA, MD5, and IDEA algorithms.
But what the heck -- I get the gist of what you are saying.

>standards allows for the use of may different types of algorithms for this
>reason.  
>
>Question:   If security is applied by an EDI security software/hardware
>solution (ANSI or EDIFACT) prior to 
>                    exchange on the internet  why do we need to worry about
>adding more security in MIME?
>                    Is there something I am missing?
> 

BECAUSE EDI Security software encrypts data within the ISA/IEA and GS/GE
leaving the envelope vulnerable to ? (hackers/sniffers/spoofers/crackers --
whatever you want to call them.

What I am worried about here is not SECRECY/CONFIDENTIALITY -- it is the
risk of LOSS OF SERVICE/ DISRUPTION OF SERVICE etc.

Why take the risk when there are encryption/digital signature options that
will take care of the entire file -- not just internal ST/SE envelopes.

>E:Mail information will be sent to anyone, rather then just trading
>partners, and should be more defined to allow you to send confidential
>information without having to worry about the algorithm which was used.
>According to your Charter this is not be decided in this work group.
>
>I agree that we must be careful that nothing is proprietary.
>

RSA is proprietary --- and not one of our options precludes the use of it.
I prefer non-proprietary, but Diffie-Hellman / El Gamal patents don't run
out until next year.  I PREFER NOT TO WAIT!!


>ANSI X12 VS EDIFACT....
>
>There has also been discussion in this group on the ANSI X12 vs EDIFACT
>standards.  Does it matter which one is used?  If both standards allow for
>different algorithms to be used then I do not see what the issue is.  Once
>the EDI message has been secured and sent over the internet, then the
>translator security product at the receivers site should be able to handle
>the data prior to EDI translation.
>
>The way the ANSI X12 standards work is that after the EDI transaction set
>has been generated by the translator, security segments are imbedded into
>the transaction set when security is applied (S1S/S2S/S1A/S2A).  These
>security segments define what algorithm was used, if a session key was used
>and the digital signature (with lots of other information... to long to type
>in).
>
>SECURITY IS STILL SLOW TO TAKE OFF...
>
>I have found that security is still something that companies and people in
>general have not thought about.  In Canada (where I live) one of the banks
>is allowing customers to apply for loans over the internet.  They send all
>their confidential information (i.e. home address, credit card numbers, how
>much they make) to the bank using the internet and their credit application
>will be processed and approved/denyed within 24 hours.
>
>INTERNATIONAL SECURITY.....
>
>International security is still something which needs to be addressed.  I
>know that the U.S.government has a real issue about this.  The DES algorithm
>is used world wide, although it cannot be exported in software (I am not
>sure if it is only sold software) without approval from the U.S. government.

If you send a PGP encrypted message out -- anybody in the world can read it
(legally ?? ) -- check out International PGP: 

http://www.ifi.uio.no/~staalesc/PGP/which-version.shtml

here is a clip:

(*) Some countries (such as France, Iran, Iraq, Russia and China) have laws
that prohibit or regulate the use of cryptography. Please check out your
country's national laws and governmental policies on cryptography before
attempting to use PGP. (See also the Crypto Law Survey.) You should also
make sure that you obtain your copy of PGP from a place outside of USA and
Canada. If you follow the links here, you should be on the safe side. 

Crypto Law Survey    http://cwis.kub.nl/~frw/people/koops/lawsurvy.htm

e.g.  a clip,

Japan [1, 3, 5]

1. COCOM regulations. Decisions are made on an individual basis.
2. no
3. Japan sees encryption as an important tool for establishing information
security in electronic commerce. It does not consider encryption a threat to law
enforcement or national security.



>This approval must be obtained for each country you are sending the software
>too.  Each approval costs approximately $10,000 and it can only be sent to a
>financial organization in the approved country.  (I know this because I was
>involved in this when I worked at Sterling).  The current gov't
>adminstration in the U.S. was trying to setup a Certification Agency
>(Nov/95)  which would maintain all private key values for all citizens in
>the U.S.   That way they could break the encryption if they needed too.   
>

<<BEGIN-PERSONAL-OPINION>> 
KEY ESCROW!  ARRRGGGG! YECHHH! BLAHH! 
<<END-PERSONAL-OPINION>>

>
>Thanks for you time... Dale
>  

GOOD MESSAGE, Post again soon!

Regards,
dave_d
======================================
|   David Darnell              
|   SysTrends, Inc.             
|   Arizona EC/EDI Roundtable   
|   1850 East Carver Road       
|   Tempe, AZ 85284             
|   Tel (602)838-5316           
|   Fax (602)897-8032           
|   mailto://dave_d@systrends.com        
======================================