From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: DMV systems? Date: Tue, 27 Dec 2005 13:55:23 -0700 Newsgroups: bit.listserv.ibm-mainas400 wrote:
previous thread ref:
https://www.garlic.com/~lynn/2005u.html#61 DMV systems?
i think sun talks about running on mainframe class machine.
original sun workstations was 68k before they produced risc sparc ...
minor reference to 68020/68030 machines
http://www.obsolyte.com/sun380/
sparc and i86 machines support ... this has minor reference to
both platforms
http://www.sun.com/software/security/securitycert/
i think that unisys logo'ed sequent's machine for a time ... as another "mainframe class" machine.
this minor reference has unisys starting logo'ing sequent machines
even before the sequent NUMA-Q machines
http://lists.freebsd.org/pipermail/freebsd-smp/2003-July/000247.html
in the 80s we participated in both fcs and sci standards activity. fci standards was somewhat the outgrowth of LLNL's work with a non-blocking copper-wire switch remapped to 1gbit/sec fiber-optics. SCI was some work out of SLAC to take fiber-optics and use it for asynchronous bus.
there had been this fiber-optic technology that had been kicking
around pok since the 70s that was having hard time getting out. part
of it appeared to be around the battle with communication division on
who "owned" stuff that crossed the wall surrounding the
glass-house. my wife was in the middle of this since she had done a
stint in POK in charge of loosely-coupled architecture ... where she
produced Peer-Coupled Shared Data architecture
https://www.garlic.com/~lynn/submain.html#shareddata
... which didn't see much uptake until parallel sysplex ... except for some work hear-and-there ... like IMS hot-standby.
in any case, supposedly the jurisdictional resolution was that CPD's terminal controller paradigm (sna) supposedly owned anything that crossed the boundary of the glass house walls.
one of the austin interconnect engineers took the pok fiber technology ... and tweaked it here and there ... getting about ten percent higher thruput (220mbits/sec rather than 200mbits/sec for escon) and used optical drivers that were at least an order of magnitude less expensive (than escon). this was announced on rs/6000 as sla (serial link adapter).
he then wanted to go on and do an 800 mbit version of sla. we convinced him to move to working on FCS ... where he became editor of the FCS standards document. part of this was that rs/6000 was much more into the market segment that highly prized interoperability ... and it was difficult to have a lot of interoperability with proprietary interconnect. an issue with FCS was basically a fully asynchronous, full-duplex operation. Later there were some horrible battles when some POK channel engineers became involved with FCS and tried to do some unnatural acts layering mainframe half-duplex channel paradigm on an underlying infrastructure that is asynchronous full-duplex (or dual simplex as i periodically refer to it) ... which i believe may now be referred to as ficon.
so in parallel with all this was the "SLAC" effort to use similar
fiber-optic technology for asynchronous bus operation rather than
asynchronous link/io operation. sci reference:
http://www.scizzl.com/
one of the reasons that we round up producing ha/cmp
https://www.garlic.com/~lynn/subtopic.html#hacmp
that was suppose to use fcs for scale-up ... minor reference
https://www.garlic.com/~lynn/95.html#13
was that RIOS chips didn't support cache coherency ... i.e. and a major SCI effort was an asynchronous memory bus implementation.
for a little more digression ... i've periodically asserted that much
of the 801/risc/romp/rios genre
https://www.garlic.com/~lynn/subtopic.html#801
was attempting to drastically simplify hardware after the disastrous
experience of future systems
https://www.garlic.com/~lynn/submain.html#futuresys
the other characteristic was that it seemed that the 801/risc had a scalded cat reation to the enormous multiprocessor cache consistency overhead exacted by the strong memory consistency paradigm of the highend mainframe 370s. not only did 801/risc go to the opposite extreme of future systems (regarding hardware complexity) ... but also the opposite extreme from highend 370s with regard to (multiprocessor) cache consistency. as a result, it was essentially impossible to build scale-up multiprocessor system with SCI and rios chips. essentially, the only scale-up fall-back was purely loosely-coupled (aka cluster) operatiion with high-speed (i/o) interconnect.
convex built 128-way exemplar with dual-processor board HP/RISC chips. SCI asynchronous memory operation standard allows for 64 memory ports. convex had dual-processor shared cache boards ... and 64 such boards allowed for maximum 128-way configuration.
both sequent and data general did something similar using 64-port SCI ... except they used intel quad-processor boards (four processors sharing cache that then used 64-port SCI to interface to memory).
this was the 256 processor Sequent numa-q machine that IBM inherited when they bought sequent. it was also the machine that unisys was logo'ing as a mainframe-class machine (but running a unix-derived operating system).
in this time-frame a separate, somewhat parallel effort was started to produce power/pc (as opposed to "power" which was the marketing name for the rios chipset) ... which would have support for cache consistency (and some number of other differences from original 801/risc/romp/rios/power).
misc. past fcs, sci, fiber, postings
https://www.garlic.com/~lynn/2000c.html#56 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2001b.html#39 John Mashey's greatest hits
https://www.garlic.com/~lynn/2001b.html#85 what makes a cpu fast
https://www.garlic.com/~lynn/2001f.html#11 Climate, US, Japan & supers query
https://www.garlic.com/~lynn/2001m.html#25 ESCON Data Transfer Rate
https://www.garlic.com/~lynn/2002e.html#32 What goes into a 3090?
https://www.garlic.com/~lynn/2002j.html#78 Future interconnects
https://www.garlic.com/~lynn/2002l.html#52 Itanium2 performance data from SGI
https://www.garlic.com/~lynn/2003h.html#0 Escon vs Ficon Cost
https://www.garlic.com/~lynn/2003j.html#65 Cost of Message Passing ?
https://www.garlic.com/~lynn/2003p.html#1 An entirely new proprietary hardware strategy
https://www.garlic.com/~lynn/2004d.html#68 bits, bytes, half-duplex, dual-simplex, etc
https://www.garlic.com/~lynn/2004p.html#29 FW: Is FICON good enough, or is it the only choice we get?
https://www.garlic.com/~lynn/2005.html#38 something like a CTC on a PC
https://www.garlic.com/~lynn/2005.html#50 something like a CTC on a PC
https://www.garlic.com/~lynn/2005d.html#20 shared memory programming on distributed memory model?
https://www.garlic.com/~lynn/2005e.html#12 Device and channel
https://www.garlic.com/~lynn/2005h.html#7 IBM 360 channel assignments
https://www.garlic.com/~lynn/2005l.html#26 ESCON to FICON conversion
https://www.garlic.com/~lynn/2005m.html#46 IBM's mini computers--lack thereof
https://www.garlic.com/~lynn/2005m.html#55 54 Processors?
https://www.garlic.com/~lynn/2005n.html#6 Cache coherency protocols: Write-update versus write-invalidate
https://www.garlic.com/~lynn/2005n.html#37 What was new&important in computer architecture 10 years ago ?
https://www.garlic.com/~lynn/2005r.html#43 Numa-Q Information
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Is Mondex secure? Newsgroups: uk.legal,sci.crypt Date: Tue, 27 Dec 2005 21:57:25 -0700Tim Smith writes:
there were some mondex people at transit meeting in the mid to late 90s. they proposed mondex card in wireless sleeves and 15ft tunnels approaching transit turnstyle. if people walked slowly thru the tunnel, by the time they reached the turnstyle the communication would have completed. i don't remember whether they required the wireless sleaves to provide battery power to the mondex card ... or whether they were trying to power from RF energy in the tunnel. I also don't know if they proposed limiting one person at a time in a tunnel.
for some drift, starting 4-6 years ago, newer generation chips could handle contactless (power derived from RF energy near reader) doing ECC public key operations within transit time requirements.
for some of the non-ecc public key infrastructures ... elapsed time in contact cards has been achieved by driving a much larger number of circuits in parallel (elapsed time somewhat inversely proportional to peak power). you might get the necessary level of power draw with contact cards ... but it was much harder to provide that much peak power for contactless cards powered with RF energy thru the air.
some of the transit chip systems use symmetric master key contained in armored, secure turnstyle readers. they read some sort of chip serial and value, compute derived symmetric key based on combination of system master key and the chip serial, decrypt the value read, update the value, re-encrypt and rewrite the chip with the new value.
within past two years, i had transit chipcard in one of the systems go from something like positive $10 balance to negative $5 balance between the time i left transit system and the next time I tried to enter the transit system. somewhere in the time outside the transit system, the chip experienced some sort of glitch. not only did the glitch cause the card to loose value ... but the balance value went negative (something the transit people weren't able to explain).
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: ABN Tape - Found Date: Wed, 28 Dec 2005 14:22:08 -0700 Newsgroups: bit.listserv.ibm-mainJeffrey.Deaver@ibm-main.lst wrote:
the internet has somewhat defocused attention from the major source of fraud (insiders) with the possibility that attacks might have originated by outsiders.
however, within the last two years or so, there was a study published finding at least 70percent of the data breach incidents (around identity theft) involved insiders.
misc. collected posts on subject of fraud, risks, vulnerabilities, etc
https://www.garlic.com/~lynn/subintegrity.html#fraud
one of the issues that we faced in x9a10 working group ... that had been given the requirement to preserve the integrity of the financial infrastructure for all retail transactions ... was how to address the issue.
one of the major issues with retail transactions is the account number
leakage resulting in fraudulent transactions
https://www.garlic.com/~lynn/subintegrity.html#harvest
the work on the original payment gateway for e-commerce involved hiding
account number transactions during transit on the internet using SSL
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
however, it was recognized that account numbers were required to be available (and therefor exposed) in a sizeable number of business processes (not just the original transaction). the conclusion was soemwhat that even if you buried the planet under miles of encryption, it still wouldn't prevent account number leakage.
the resulting x9a10 standard work for x9.59 transactions
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959
resulted in following standard specification:
1) x9.59 transactions are strongly authenticated (using dynamic data) 2) information (including account number) used in x9.59 transactions could not be used in non-authenticated, non-x9.59 transactions.
a major threat in payment card retail transactions has been the account numbere leakage/harvesting and then using the information in a form of replay attack (using the same information to perform a fraudulent transaction). the replay attack vulnerability effectively forces the account number into being treated as a form of shared-secret (if it is known than it is possible to perform a fraudulent operation, akin to stealing passwords).
the x9.59 standard includes replay attack countermeasure ... none of the information from an x9.59 transactions can be harvested and then turned around to be used in fraudulent transaction. this eliminates knowledge of the account number as a vulnerability. evesdropping, data breaches, and/or havesting attacks involving (x9.59) account numbers no longer result in fraudulent transactions (i.e. no longer necessary to treat x9.59 account numbers as if they were shared-secrets/passwords)
this in turn gets back to the assertion about non-x9.59 account transactions, that even burying the whole planet under miles of encryption is not sufficient to prevent account number leakage ... in part because of the large number of different business processes requiring the account number (as well as the insider vulnerability issue).
for a little drift, recent thread regarding various SSL vulnerability
issues
https://www.garlic.com/~lynn/aadsm21.htm#41 X.509 / PKI, PGP, and IBE Secure Email Technologies
https://www.garlic.com/~lynn/aadsm21.htm#39 X.509 / PKI, PGP, and IBE Secure Email Technologies
https://www.garlic.com/~lynn/aadsm21.htm#40 X.509 / PKI, PGP, and IBE Secure Email Technologies
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: ABN Tape - Found Newsgroups: bit.listserv.ibm-main Date: 28 Dec 2005 21:56:15 -0800Hal Merritt wrote:
was recently one of the co-authors of the financial industry x9.99 privacy impact assesement (PIA) standard ... basically defining a standard for auditing infrastructure. part of the challenge was to define an assesement standard that could accommodate a variety of different jurisdictional regulatory and legislative requirements. Part of it was keeping in mind that possibility of promoting x9.99 to international/ISO standard ... so the breadth and range of regulatory and legislative differences wouldn't just involve US jurisdictions ... but might span the whole world. the other issue was to attempt to avoid having PIA standard becoming obsolute not only with multi-jurisdiction but also changes that might occur over time.
we were asked to come in and do some work on the cal. state electronic
signature legislation
https://www.garlic.com/~lynn/subpubkey.html#signature
and then later the fed. electronic signature legislation. one of the participating industry groups was also working on various privacy issues and had done a survey of the primary driving factors behind privacy regulation and legislation. they found one of the primary driving factors behind privacy regulation and legislation was id-theft.
for some topic drift ... there has been an attempt to differentiate id-theft where a crook harvests account numbers and uses the information for fraudulent transactions against existing accounts ... from identification theft where somebody uses personal information for opening new accounts.
the previously mentioned work on x9.59 was to use strong authentication and business rules to drastically reduce the vulnerability associated with account numbers.
there is a security model called PAIN
P - privacy (or confidentiality)
A - authentication
I - integrity
N - non-repudiation
in the case of account fraud, frequently knowledge from a previous
transaction is sufficient to enable a future fraudulent transaction.
This can somewhat be viewed as a from of replay attack. Account numbers
effectively then have to be treated as a form of secret or password
https://www.garlic.com/~lynn/subintegrity.html#secret
a lot of attention has been focused on using privacy (hiding and/or
encryption) as a countermeasure to account fraud ... by attempting to
drastically limit means for obtaining knowledge of account numbers.
the x9a10 standards work observed that the account number is needed in
so many business processes that it practically impossible to prevent
account number information leakage.
https://www.garlic.com/~lynn/subintegrity.html#harvest
as a result, the x9.59 approach was to use strong authentication
(instead of privacy) as a countermeasure to account fraud (knowledge of
previous transactions and/or account numbers is no longer sufficient for
performing fraudulent transactions). previous post
https://www.garlic.com/~lynn/2005v.html#2 ABN Tape - Found
minor digression, as part of doing the work on x9.99 PIA standard, I
attempted to pull together a privacy merged taxonomy and glossary,
drawing heavily on earlier work on payments, financial, security, etc
https://www.garlic.com/~lynn/index.html#glosnote
for even more topic drift ... the electronic signature legislation differed significantly from earlier work on digital signature legislation. there was some conjunction that semantic confusion arose because the term human signature and digital signature both contain the word signature. the issue is that digital signature business process is used for authentication (and integrity). human signature (and electornic signature) attempts to address the issue of human reading, understanding, agreeing, approvaing, and/or authorizing.
I've actually explored in some number of postings the issue of creating systemic risk when there is an attempt to use digital signatures for both authentication purposes and also confused with human signature.
some number of postings on dual-use attacks and/or what does a digital
signature represent:
https://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#56 two-factor authentication problems
https://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm19.htm#43 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm20.htm#0 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm21.htm#5 Is there any future for smartcards?
https://www.garlic.com/~lynn/aadsm21.htm#13 Contactless payments and the security challenges
https://www.garlic.com/~lynn/2002i.html#67 Does Diffie-Hellman schema belong to Public Key schema family?
https://www.garlic.com/~lynn/2004h.html#47 very basic quextions: public key encryption
https://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#21 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2005.html#14 Using smart cards for signing and authorization in applets
https://www.garlic.com/~lynn/2005b.html#56 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005e.html#31 Public/Private key pair protection on Windows
https://www.garlic.com/~lynn/2005e.html#43 Actual difference between RSA public and private keys?
https://www.garlic.com/~lynn/2005g.html#46 Maximum RAM and ROM for smartcards
https://www.garlic.com/~lynn/2005l.html#7 Signing and bundling data using certificates
https://www.garlic.com/~lynn/2005l.html#25 PKI Crypto and VSAM RLS
https://www.garlic.com/~lynn/2005l.html#35 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005m.html#1 Creating certs for others (without their private keys)
https://www.garlic.com/~lynn/2005m.html#11 Question about authentication protocols
https://www.garlic.com/~lynn/2005m.html#15 Course 2821; how this will help for CISSP exam ?
https://www.garlic.com/~lynn/2005m.html#18 S/MIME Certificates from External CA
https://www.garlic.com/~lynn/2005m.html#27 how do i encrypt outgoing email
https://www.garlic.com/~lynn/2005m.html#45 Digital ID
https://www.garlic.com/~lynn/2005n.html#33 X509 digital certificate for offline solution
https://www.garlic.com/~lynn/2005n.html#39 Uploading to Asimov
https://www.garlic.com/~lynn/2005o.html#3 The Chinese MD5 attack
https://www.garlic.com/~lynn/2005o.html#6 X509 digital certificate for offline solution
https://www.garlic.com/~lynn/2005o.html#17 Smart Cards?
https://www.garlic.com/~lynn/2005o.html#42 Catch22. If you cannot legally be forced to sign a document etc - Tax Declaration etc etc etc
https://www.garlic.com/~lynn/2005p.html#33 Digital Singatures question
https://www.garlic.com/~lynn/2005q.html#13 IPSEC with non-domain Server
https://www.garlic.com/~lynn/2005q.html#23 Logon with Digital Siganture (PKI/OCES - or what else they're called)
https://www.garlic.com/~lynn/2005q.html#29 IPSEC wireless router ?
https://www.garlic.com/~lynn/2005s.html#42 feasibility of certificate based login (PKI) w/o real smart card
https://www.garlic.com/~lynn/2005s.html#43 P2P Authentication
https://www.garlic.com/~lynn/2005s.html#52 TTP and KCM
https://www.garlic.com/~lynn/2005t.html#32 RSA SecurID product
https://www.garlic.com/~lynn/2005t.html#52 PGP Lame question
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: ABN Tape - Found Date: Wed, 28 Dec 2005 23:24:43 -0700 Newsgroups: bit.listserv.ibm-mainHal Merritt wrote:
Merchants unsecure, poll
http://www.crime-research.org/news/28.12.2005/1723/
from above:
A poll released by Protegrity Corporation, a provider of data security
management solutions, found that Payment Card Industry Data Security
Standard (PCI) compliance is severely lagging at merchants of all
levels despite a growing Internet fraud rate.
... snip ...
and discussion of a different part of the issue in this post that i
frequently refer to as security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61
when we were originally talking about deploying what is now called
e-commerce
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
we discussed a number of requirements for operation of web merchants
... including things like requiring FBI background checks on all
merchant and merchant employees. a few past posts mentioning the
subject
https://www.garlic.com/~lynn/2001j.html#5 E-commerce security????
https://www.garlic.com/~lynn/2001j.html#54 Does "Strong Security" Mean Anything?
https://www.garlic.com/~lynn/aadsm21.htm#20 Some thoughts on high-assurance certificates
https://www.garlic.com/~lynn/aadsm21.htm#34 X.509 / PKI, PGP, and IBE Secure Email Technologies
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: famous literature Newsgroups: sci.crypt Date: Thu, 29 Dec 2005 00:57:02 -0700"jay25dec@gmail.com" writes:
note the comments about public/private key business process where one key (of a asymmetric key pair) is identified as public and made generally/widely available ... the other key is identified as private and kept confidential and never divulged.
digital certificates provide binding between some information and a public key ... somewhat targeted as first time communication between strangers (the letters of credit/introduction paradigm from sailing ship days).
recent thread with discussion of some digital certificate (PKI) based
and certificate-less (public key) infrastructures (some common features
as well as differences) :
https://www.garlic.com/~lynn/aadsm21.htm#26 X.509 / PKI, PGP, and IBE Secure Email Technologies
https://www.garlic.com/~lynn/aadsm21.htm#27 X.509 / PKI, PGP, and IBE Secure Email Technologies
https://www.garlic.com/~lynn/aadsm21.htm#28 X.509 / PKI, PGP, and IBE Secure Email Technologies
https://www.garlic.com/~lynn/aadsm21.htm#29 X.509 / PKI, PGP, and IBE Secure Email Technologies
https://www.garlic.com/~lynn/aadsm21.htm#30 X.509 / PKI, PGP, and IBE Secure Email Technologies
https://www.garlic.com/~lynn/aadsm21.htm#31 X.509 / PKI, PGP, and IBE Secure Email Technologies
https://www.garlic.com/~lynn/aadsm21.htm#33 X.509 / PKI, PGP, and IBE Secure Email Technologies
https://www.garlic.com/~lynn/aadsm21.htm#34 X.509 / PKI, PGP, and IBE Secure Email Technologies
https://www.garlic.com/~lynn/aadsm21.htm#39 X.509 / PKI, PGP, and IBE Secure Email Technologies
https://www.garlic.com/~lynn/aadsm21.htm#40 X.509 / PKI, PGP, and IBE Secure Email Technologies
https://www.garlic.com/~lynn/aadsm21.htm#41 X.509 / PKI, PGP, and IBE Secure Email Technologies
general collected postings on certificate-less public key operation
https://www.garlic.com/~lynn/subpubkey.html#certless
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: DMV systems? Date: Fri, 30 Dec 2005 15:40:48 -0700 Newsgroups: bit.listserv.ibm-mainBruce Black wrote:
they had tried running mainframe under an operating system ... but found that MTBF for MVS was on the order of 15 minutes (i.e. single dasd testcell could generate more errors ... including all sorts of architecture violations ... in 15 minutes than most shops would experience in years).
as a result, they had to resort to doing all testing with dedicated, stand-alone processor time on a testcell by testcell basis.
as a fun exercise, i undertook to rewrite i/o supervisor (including error recovery and recording) so they could concurrently test multiple testcells in normal operating system environment (w/o having to take all the machines down for stand-alone, dedicated machine time) ... which drastically increased productivity (i/o supervisor was bullet proof and never failed)
misc. collected postings about bldg. 14 and 15 work
https://www.garlic.com/~lynn/subtopic.html#disk
From: Anne & Lynn Wheeler <lynn@garlic.com> Date: Fri, 30 Dec 2005 17:30:32 -0700 Subject: (at least smp) fc5 kernels after 1788 have excessive kernel overhead Newsgroup: fedora-test-listdell poweredge 2400 dual 1ghz processors. (at least smp) kernels after 1788 have enormous kernel processor overhead.
applications that are i/o bound on kernel 1788 or earlier ... are severely degraded on kernels after 1788 with 100% processor utilization .... almost all of it in kernel. when applications are idle ... the processor use goes idle (aka it isn't some sort of background looping process ... but seems to be some sort extra kernel overhead). an enet transfer that normally sustains 2.5mbytes/sec with maybe 20 percent cpu utilization only does 600kbytes/sec with 100precent cpu, almost all in the kernel (apporx. 20 times more processor executed per byte transferred)
this is machine that i had problems with scsi i/o hanging after fc4 smp kernel 1278 (non-smp kernel didn't have scsi i/o hang problem). smp kernel hanging problem cleared up with fresh fc5 install.