Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
Our voting machines are a series of buttons on the outside of a continuous sheet of paper. You can go page to page with buttons. each button is supposed to point at a candidate/proposal. It didn't work that way. When I went through the ballot I found several pages that pointed at the lines between the selections, and not at a selection. I found that it was not possible to push the button for Clinton, but was possible to push the button above Bush. I also found that went I paged forward, and back that the lit buttons didn't point at the people I had voted for. I pointed this out to the election judges and was told that "They only deal with the totals, and therefore it would all average out" Ray Todd Stevens, Contractor, Resource Protection Dept NSWC Crane Div. Ray@safety.nwscc.sea06.navy.mil (812) 854-3292 854-3294 854-3289
The 12 November 1992 issue of the weekly UK newspaper "Computing" has a three
page spread (pp18-21) on safety-critical systems entitled "Safe Conduct" by
Clair Neesham. In particular, new piece of EC legislatation, the Machine Safety
Directive, comes into effect in the UK on 1 January 1993. This encompasses
software and if there is an error in the machine's logic that results in injury
then a claim can be made under civil law against the supplier. If negligence
can be proved during the product's design or manufacture then criminal
proceedings may be taken against the director or manager in charge. There will
be a maximum penalty of three months in jail or a large fine. (This actually
sounds rather low to me.) Suppliers will have to demonstrate that they are
using best working practice including, for example, risk analysis and project
planning. The DTI-funded (Department of Trade and Industry) Safety-Critical
Systems Club is helping to raise awareness of the issues in the UK with regular
meetings and a newsletter. A knowledge of relevant standards is important
(e.g., ISO9001, 00-55 & 00-56, DO-178, ...). Formal methods (e.g., Z, VDM and
B) are cited as one way of improving matters, but judging from the "site study"
boxes in the article, there is still considerable scepticism in industry about
their applicability at the moment, due to lack of trained personnel, problems
of scaling up, worries about extra cost, etc. However, they are seen as
promising for the future.
Jonathan Bowen, Oxford University
I number of years ago I was called in as a consultant to look into a suspected case of fraud. The reason for the belief that there was fraud involved was that one of their low paid clerks had retired, and at the end of the year they give out attendance awards. They wanted this person to pick up his "20 years without a sick day" award at the awards banquet, and attempted to invite him. They found out that this guy had been living it up as a jet setter. Someone decided to find out how he could afford it. It was not hard to figure out. This guy was in charge of all office supplies for the Corp (a large multinational). This meant that he was in charge of ordering and then confirming receipt of supplies. He was supposed to keep an inventory on hand, (central management to the max) and ship out supplies as needed. The supposed control was the the office managers were supposed to confirm that they received what he said he sent them. He was able to set up a phony company and order goods from it he then receipted in the goods, and include these in shipments. If he had missed just one day he would never have been caught. By the way he basically got a way with it. I return for keeping his mouth shut about where he got the money he got to keep all of the interest, and way not prosecuted. Ray Todd Stevens, Contractor, Resource Protection Dept NSWC Crane Div. Ray@safety.nwscc.sea06.navy.mil (812) 854-3292 854-3294 854-3289
(Based on an article in Vrij Nederland of 31 October, 1992.) For years the Dutch banks have stated that they do not store the PIN code required for many transactions using cards. They imply that if somebody reports illegal use of the card plus PIN code this is only because the owner of the card has not been careful enough with his code. They also told us that there is no way to calculate the code given an account number only. And they also imply that a 4-digit PIN code is sufficient for security (as many know, this is not true). It has now been revealed that some banks routinely tell customers their PIN code if they did forget it. There is one case on record where during a criminal investigation the police wondered whether a particular number written down by the person under investigation was the PIN code connected to a particular account. They just asked the bank for the PIN code for the account and received it back, the number as written down was just the code in reverse. More interesting is here that even though the banks do not store actual PIN codes (and as such are technically correct in some of their statements), some have the data available to calculate the code even if the card is not available. They still maintain the system is safe. dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland home: bovenover 215, 1025 jn amsterdam, nederland; e-mail: dik@cwi.nl
When I talk on cellular phones, I already take precautions by making allusions to other events and taking full advantage of the shared context so that the message is innocuous the the casual listeners. This is the norm for aware people in any case where there is a concern about the possibility of being overheard. Teflon John wouldn't be caught dead (or would be dead if caught?) being too direct over a potentially public (i.e. tappable) channel. This technique works even without intent to be secret — just listen to two MIT students planning their courses for the following semester. The real issue is exchanging large amounts of data or regular transmissions such as financial transactions among a large community of users so that all the information about the techniques is public and all that is hidden are the keys. BTW, it has long been the case that encryping over Telex by using code words, or even nonEnglish words, has been illegal in many countries.
Mr. Robert Gezelter writes in RISKS-14.04 about cellular phones being used "in
aircraft (at least those operating under Instrument Flight Rules)".
First of all, the FAA (Federal Aviation Administration) leaves the decision of
the use of electronic equipment in aircraft up to the operator of the aircraft.
This means, essentially, the aircraft's owner: either me, in the case of my own
plane, or the company operating the aircraft: American Airlines, for instance.
The frequencies that cellular phones operate on do not directly conflict with
aviation frequencies, but some poorly designed phones could emit RFI (harmonics
of the carrier, or IF frequencies for example) in frequencies that could
interfere with navigation equipment. Usually this is not a problem, though, as
most avionics gear is tolerably well shielded.
Secondly, the FCC (Federal Communications Commission) is the one that bans
cellular phone use in aircraft, whether under Instrument Flight rules or not.
It turns out that when a cellular phone at, say, 20,000 feet tries to make a
call it will wake up cells for hundreds of miles around and badly confuse the
system, which is expecting to get a signal from only a few cells at once.
The blanket ban *is* due to cell overlap, then, and my guess is the reason
there is not an altitude restriction is that it's too hard to figure out; the
number of cells reached is a complex function of altitude, position of the
aircraft and cells, and the topography of the surrounding landscape. I can
just picture the FCC bureaucrat saying ``Hell, that's too hard. Let's just ban
'em all.''.
--berry
CMARTIN@nswc.navy.mil wrote about the then-new voice mail system installed at
Maryland, and the problems which ensued when students discovered that all the
pass codes were set the same. One lesson he suggested from this was to the
engineers, who should either make the codes different, or make a better attempt
to warn users about the situation.
The education needs to be given regularly to new employees and also visitors,
else they can become special targets of locals who already "know the system".
As case in point, I cite one of my own (many) experiences with the UM voice
mail system that CMARTIN mentions. A few months ago I was given a new office,
whose previous occupant had been a prestigious visitor. My own phone number
lagged behind the move by a few days, so I temporarily got use of phone account
of our visitor, Nancy Leveson. Guess who didn't get the word to change the
default passcode!
Don't worry, Nancy, none of the messages sounded urgent. :-)
I discovered you can learn a lot about someone by playing with their
intelligent phone system. The "redial" button suggested a last user might have
ordered a carry out meal from Cluck-U-Chicken, a popular campus town eatery at
the time. (If the place had used caller-ID like so many carry-out businesses
these days, then I suppose I could have just ordered the "usual" and found out
the previous user's tastes too.) I thought it best not to see where the "speed
dialing" buttons got me. But does anyone know of stock brokers or doctors
offices use caller-ID as a check for letting callers request a transaction or
access info?
CMARTIN did not report the most fun aspect of the voice mail system, which was
not generally open to students. It was (notice past tense) "call pickup"....
intended, I presume, as convenience in a large office, it lets you answer a
call to your number from someone else's phone. After hearing a distinctive
ring, say while you are down the hall, you can hit one button and get the next
incoming call, picking it up. Well .... as we know so much in this business,
"programming in the small" is not the same as "programming in the large". The
call pickup feature does not scale, as we demonstrated empirically. Some
thoughtful soul had spec'd call pickup in our new system, but, to save money
set up the entire CS department on the same "group". (We were told this was to
save money... one paid per group, where "group" was a set of numbers within
which the pickup feature would work.) The net result of this was that whenever
a professor got bored, he or she could play call-pickup-roulette ... that is,
pick up the phone, punch the "pickup number" and see if anyone was calling
*anyone* in the building. That is, you could intercept any incoming call with
lucky timing. (I should note that John Gannon had demonstrated a keen
proficiency in this technique.) The entertaining part of this was how you
handled the call, which I leave to the reader's imagination.
John has a fertile imagination, especially when egged on by his office
neighbor. The feature didn't last long.
Jim
Here is a chance to help get some equipment which will be widely used by the public to work right from the start. A friend of mine in the communications industry is a member of a committee made of representatives of equipment manufacturers. They are not experts in designing or testing protocols, but are designing several which will be used to accept messages from the public, carry them between equipment made by the several companies, ending in a radio receiver interfaced to the end user's computer. If things go as they have in the past, the protocols may be far from robust. I am not identifying the parties involved, and I hope that none of them take offense. None is intended. Learning to design protocols is not so easy. Just being smart is not enough. No doubt the "obviously difficult" parts, like the radio forward error correction, will be done properly. It is the "easy" parts involving asynchronous communications that are likely to be defective in nonobvious ways. One likely defect is that not every manufacturer's equipment will work properly with the others. This is a source of cost, and is the primary reason the question of validating the equipment and protocols came up. But of course, if that sort of defect can arise, probably others which cause the public harm might also arise. Anyway, I will capture and forward any e-mail I receive on the subject to the committee. Maybe they can be persuaded to publish the protocols in a suitable Usenet newsgroup, or elsewhere, for comment. Maybe they can also be persuaded to make eavesdropping difficult. Recommendations of books, papers, testing software, or qualified experts, is solicited. The correct reply address is "huff@mcclb0.med.nyu.edu"
>It's already a cliche, but it's still true: when cryptography is outlawed,
>only outlaws will use cryptography. (And no, I *don't* believe the same
>is true for guns.)
Realizing that anyone who wants it can recover it, I have excised the signature
from this quotation because the author only made himself a representative of a
large class of fuzzy thinkers when he wrote it.
Consider the proposition:
If X is outlawed, then only outlaws will {have|use} X.
The hypothesis of that proposition is merely a statement that some legislative
body has declared the consequent to be true. The proposition is a tautology,
true for all possible values of the variable X.
In particular, it is true for typewriters. I believe the samizdat caused at
least one legislative body to substitute typewriter into the proposition for X.
It is true for photocopiers. It is true for orange peels, though I don't know
of any legislature that has outlawed orange peels.
Most of us are in professions where logic is of some importance. It hurts
credibility to declare in public, "I *don't* believe" a tautology.
dan herrick dlh%dlhpfm@NCoast.org
Credit fraud is a particular concern of mine because I'm going through a similar situation. What I found interesting about the article posted by Mr. Robinson was a parallel to previous well known computer system failures. In his October 20 talk at MIT, Mr. Neumann pointed out [some of the problems of] not learning from our mistakes. The 1980 ARAPANET failure and the 1990 AT&T failure were both caused by propagation of invalid packets across a network (conceptually speaking, at least). Cleaning up a corrupted credit record is a similar problem. Given the sharing of credit data, one has to remove the incorrect information from all credit database simultaneously, or it's likely to spread throughout the system again! In addition, there's a security risk: the owner of any credit database can insert faulty information and it will then be propagated throughout the system. michael j. zehr
<> ... Eventually a screw-up elsewhere in the system
<> forced a thorough enough audit to plug the hole for one set of
<> transactions, leading to the transgressor's arrest]
The error, of course, had no essential role in catching the embezzler. What
had to happen is that occasionally the accounting thoroughness had to far
exceed the bounds of cost-effectiveness.
The random process is all too often an error of some sort, but i understand
that banks do an extreme audit on each branch every six months or so, at random
times.
-dk
I just thought that readers of RISKS might like to know that IBM Australia has a newly installed phone system that shows the calling number much of the time. There has been no public comment (that I have seen) about the availability of such information, or any way to turn it off. Most people I have talked to don't know that the feature is available. I spoke to our Telecom representative. Both ACCI and IBM Australia are ISDN customers, and Caller-ID is a standard feature of ISDN. Individual customers get to enable or disable outgoing caller identification at the time they get the service. By default the outgoing information is the phone number, but the PABX can be programmed to send alphanumeric information, such as the caller's name! (According to the techie I talked to, most ISDN customers do allow their identification information to go out, although some don't. Either way, the customer has to specifically address the question. ACCI allows the Caller-ID information even though our own handsets don't have display capability.) Caller-ID for non-ISDN customers is technically available on most newer exchanges, but AUSTEL, the regulatory authority now that Telecom has competition, has not yet allowed general access until they address the privacy issues. I was impressed by this answer, both that it seems Australia is addressing the issues pro-actively rather than waiting for a hoo-haa to occur, and also because it was not particularly difficult to get the information. Greg Rose Australian Computing and Communications Institute ggr@acci.com.au +61 18 174 842
If you're concerned about UNIX security, you might plan to be at the Sun User Group Conference (San Jose Convention Center) on Monday, December 7, 1992. The Conference and Exhibition extends through Thursday. In the all-day tutorial "Advanced Unix Security", Matt Bishop (Dartmouth University) will examine four areas critical to the functioning of secure Unix systems: user authentication, management of privileges, defending against malicious logic, and networking. Concurrently Brent Chapman (Great Circle Associates) will lead a morning session on "Preparing for Disaster" and Bob Baldwin (Tandem Computers) will answer the question "Why have Computer Security?" during the afternoon. Special offer: 5 full conference registrations (each includes a day of tutorial) for the price of 4 when preregistering with a single payment. Other full-day tutorials: * Sun Network Debugging (Smoot Carl-Mitchell, Texas Internet Consulting) * Topics in Perl (Tom Christiansen, Convex Computer Corporation) * Programming in POSIX (Jeffrey S. Haemer, Canary Software) * UNIX Programming Tools (Kenneth Ingham, consultant) * The Internet and its Protocols (William LeFebvre, Northwestern University) * Introduction to UNIX System Administration (Dinah McNutt, Tivoli Systems) * Integrating C Code and Xt Widgets (Craig Rudlin, MD, Medical Software and Computer Systems) If you just want to go to the exhibits, ask for a free show-only pass. To get more information by email about these tutorials, the technical program, or exhibits at the Sun User Group conference, send requests to sugshow@sug.org . You will receive the full tutorials and program description with registration information. Or call 1-800/727-EXPO. (Outside the U.S., use 512/331-7761 (voice) or 512/331-3950 (FAX).) Nancy Frishberg, Sun User Group.
MONDAY, 14TH DECEMBER 1992
Session 1: AUTHENTICATION AND SECRET SHARING I
(9.00-9.50)
Threshold cryptography (invited talk)
Y. Desmedt (University of Wisconsin-Milwaukee, US),
(9.50-10.10)
Authentication codes with perfect protection,
L. Tombak, R. Safavi-Naini (University of Wollongong, Australia)
(10.10-10.30)
Practical proven secure authentication with arbitration
Y. Desmedt (University of Wisconsin-Milwaukee, US),
J. Seberry (university of Wollongong, Australia)
Session 2: AUTHENTICATION AND SECRET SHARING II
(11.00-11.20)
Authentication codes under impersonation attack,
R. Safavi-Naini, L. Tombak (University of Wollongong, Australia)
(11.20-11.40)
Cumulative arrays and geometric secret sharing schemes,
W.A. Jackson (Royal Holloway and Bedford New College, UK),
K.M. Martin (University of Adelaide, Australia)
(11.40-12.00)
Nonperfect secret sharing schemes,
W. Ogata, K. Kurosawa (Tokyo Institute of Technology, Japan)
(12.00-12.20)
A construction of practical secret sharing schemes
using linear block codes,
M. Bertilsson, I. Ingemarsson (Linkoping University, Sweden)
Session 3: SIGNATURES AND HASHING ALGORITHMS
(13.40-14.00)
HAVAL --- a one-way hashing algorithm with variable length of output,
Y. Zheng, J. Pieprzyk, J. Seberry (University of Wollongong, Australia)
(14.00-14.20)
On the power of memory in the design of collision
resistant hash functions,
B. Preneel, R. Govaerts, J. Vandewalle (Katholieke Univesiteit
Leuven, Belgium)
(14.20-14.40)
A practical digital multisignature scheme based on discrete logarithms,
T. Hardjono (ATR Communication Research, Japan),
Y. Zheng (University of Wollongong, Australia)
(14.40-15.00)
Group-oriented undeniable signature schemes without
the assistance of a mutually trusted party,
L. Harn (University of Missouri-Kansas City, US),
S. Yang (University of Science and Technology of China, PRC)
Session 4: THEORY OF S-BOXES
(15.30-15.50)
Highly nonlinear 0-1 balanced Boolean functions satisfying
strict avalanche criterion,
X.M. Zhang, J. Seberry (University of Wollongong, Australia)
(15.50-16.10)
Linear nonequivalence versus nonlinearity,
C. Charnes, J. Pieprzyk University of Wollongong, Australia)
(16.10-16.30)
Constructing large cryptographically strong S-boxes,
J. Detombe, S. Tavares (Queen's University, Canada)
TUESDAY, 15TH DECEMBER 1992
Session 5: CRYPTANALYSIS
(9.00-9.50)
Wire tape channel (invited talk)
V. Korjik (Bronch-Bruevitch Technical Communications University,
St Petersburg, Russia)
(9.50-10.10)
Cryptanalysis of LOKI91,
L.R. Knudsen (Aarhus University, Denmark)
(10.10-10.30)
Cryptanalysis of summation generator,
E. Dawson (Queensland University of Technology, Australia)
Session 6: PROTOCOLS I
(11.00-11.20)
Secure addition sequence and its application
on the server aided secret computation protocols,
C.S. Laih, S.M. Yen (National Cheng Kung University, Taiwan)
(11.20-11.40)
Subliminal channels for signature transfer and their
application to signature distribution schemes,
K. Sakurai (Mitsubishi Electric Co., Japan),
T. Itoh (Tokyo Institute of Technology, Japan)
(11.40-12.00)
A practical secret voting scheme for large scale elections,
A. Fujioka, T. Okamoto, K. Ohta (NTT, Japan)
(12.00-12.20)
Privacy for multi-party protocols,
T. Satoh, K. Kurosawa (Tokyo Institute of Technology, Japan)
Session 7: PROTOCOLS II
(13.30-13.50)
New protocols for electronic money,
J.C. Pailles (SEPT, France)
(13.50-14.10)
Modeling and analyzing cryptographic protocols using Petri nets,
B.B. Nieh, S.E. Tavares (Queen's University, Canada)
(14.10-14.30)
On verifiable implicit asking protocols for RSA computation,
T. Matsumoto, H. Imai (Yokohama National University, Japan),
C-S. Laih, S-M. Yen (National Cheng Kung University, Taiwan)
(14.30-14.50)
Modified Maurer-Yacobi's scheme and its applications,
C.H. Lim, P.J. Lee (Pohang Institute of Science and Technology, Korea)
Session 8: SEQUENCES
(15.20-15.40)
The vulnerability of geometric sequences based on
fields of odd characteristic,
A. Klapper (University of Manitoba, Canada)
(15.40-16.00)
A fast cryptographic checksum algorithm based on stream ciphers,
X. Lai, R.A. Rueppel, J. Woollven (R^3 Security Engineering,
Switzerland)
(16.00-16.20)
An approach to the initial state reconstruction of a clock-controlled
shift register based on a novel distance measure,
M. Mihaljevic (University of Belgrade, Yugoslavia)
(16.20-16.40)
Construction of m-ary de-Bruijn sequences,
J.H. Yang, Z.D. Dai (Academia Sinica, China)
WEDNESDAY, 16TH DECEMBER 1992
Session 9: PSEUDORANDOMNESS
(9.00-9.50)
Information technology security standards (invited talk)
J. Snare (Telecom Research Laboratories, Australia)
(9.50-10.10)
Non-interactive generation of shared pseudorandom sequences,
M. Cerecedo, T. Matsumoto, H. Imai (Yokohama National University, Japan)
(10.10-10.30)
A generalized description of DES-based and Benes-based
permutation generators,
M. Portz (RWTH Aachen, Germany)
Session 10: ODDS AND ENDS
(11.00-11.20)
Prime generation with the Demytko-Miller-Trbovich algorithm,
L. Condie (University of New England, Australia)
(11.20-11.40)
Construction of feebly-one-way families of permutations,
A.P. Hiltgen (Swiss Federal Institute of Technology, Switzerland)
(11.40-12.00)
On bit correlations among preimages of "many to one" one-way functions,
K. Sakurai (Mitsubishi Electric Co., Japan),
T. Itoh (Tokyo Institute of Technology, Japan)
(12.00-12.20)
A fast cascade exponentiation algorithm and its
application on cryptography,
S.M. Yen, C.S. Laih (National Cheng Kung University, Taiwan)
Session 11: PUBLIC KEY CRYPTOGRAPHY I
(13.30-14.20)
Public key generation --- state-of-the-art (invited talk)
P. Landrock (Aarhus University, Denmark)
(14.20-14.40)
The design of a conference key distribution system,
C.C. Chang (National Chung Cheng University, Taiwan),
T.C. Wu (National Chiao Tung University, Taiwan),
C.P. Chen (National Chung Cheng University, Taiwan)
(14.40-15.00)
Public-key cryptosystem based on the discrete logarithm problem,
L. Harn (University of Missouri-Kansas City, US),
S. Yang (University of Science and Technology of China, PRC)
Session 12: PUBLIC KEY CRYPTOGRAPHY II
(15.30-15.50)
Elliptic curves over Fp suitable for cryptosystems,
A. Miyaji (Matsushita Electric Industrial Co., Japan)
(15.50-16.10)
New public-key cryptosystems based on factorization of finite groups,
M. Qu, S.A. Vanstone (University of Waterloo, Canada)
(16.10-16.30)
The probability distribution of the Diffie-Hellman key,
C.P. Waldvogel, J.L. Massey
(Swiss Federal Institute of Technology, Switzerland)
(16.30-16.50)
A modular unit based on systolic arrays,
J. Sauerbrey (Technische Universitat Munchen, Germany)
(16.50-17.10)
A comparison of key distribution patterns
constructed from circle geometries,
C.M. O'Keefe (University of Adelaide, Australia)
For more information, please contact
Auscrypt'92 Secretary, Office of Educational Services
Queensland University of Technology, G.P.O. Box 2434
Brisbane, QLD 4001 Australia
Fax: +61-7-864 3529 Phone: +61-7-864 2822
Email: zsrcdawson@qut.edu.au (Ed Dawson) or
w_caelli@qut.edu.au (Bill Caelli)
Please report problems with the web pages to the maintainer