Date: Wed, 08 Jul 92 16:44:40 EST
Errors-To: Comp-privacy Error Handler <comp-privacy-request@PICA.ARMY.MIL>
From: Computer Privacy Digest Moderator <comp-privacy@PICA.ARMY.MIL>
To: Comp-privacy@PICA.ARMY.MIL
Subject: Computer Privacy Digest V1#059
Computer Privacy Digest Wed, 08 Jul 92 Volume 1 : Issue: 059
Today's Topics: Moderator: Dennis G. Rears
Re: SSNs and Social Insurance Numbers
Re: Caller ID decision
Information Technology Security Evaluation Manual (ITSEM) V0.2
Re: SSNs and Social Insurance Numbers
The Computer Privacy Digest is a forum for discussion on the
effect of technology on privacy. The digest is moderated and
gatewayed into the USENET newsgroup comp.society.privacy
(Moderated). Submissions should be sent to
comp-privacy@pica.army.mil and administrative requests to
comp-privacy-request@pica.army.mil.
Back issues are available via anonymous ftp on ftp.pica.army.mil
[129.139.160.200].
----------------------------------------------------------------------
From: rwhit@cs.umu.se (Randall Whitaker)
Subject: Re: SSNs and Social Insurance Numbers
Organization: Dep. of Info.Proc, Umea Univ., Sweden
Date: Sat, 4 Jul 1992 18:56:23 GMT
In <comp-privacy1.58.1@pica.army.mil> towers.rn.com!brian@homebase.vistachrome.com (Brian Murrey) writes:
>Not sure if this is still true, but at least 7 years ago the ABC part of the
>SSN was an indication as to what state the SSN was issued in. I used to do
>some skip tracing for a major plastic credit company and we had a sheet that
>identified where the first 3 digits belonged. IE: 303 is Indiana, though many
>states had 3 or 4 prefixes assigned to them.
>
>I also remember that there were two or three "special" prefixes reserved for
>Railroaders, Government Dependents, and another special group that I can't
>remember.
Hej:
I was a claims rep. for SSA from the 1970's through the mid-80's. We were
trained in all this stuff. I can tell you what I recall of the specifics
as they are accessible from memory.
NOTE: This is the 3rd time I've contributed this info to this group. Is
there a FAQ? Should there be one?
The points above are vaguely correct.
Returning to the coding scheme used in another posting in this thread, i.e.:
ABC-DE-FGHI for the 9-digit SSN
(I forget the precise nomenclature, so bear with me).....
ABC: This is a block number. It denotes an entire "block" or set of
numbers to be assigned. The blocks were originally assigned back in the
early days (late 1930's). Additional blocks were opened as they became
needed. The originally anticipated distribution of the blocks didn't work
out due to demographic shifts (especially migration to the South and West).
These blocks are NOT assigned by state. They are assigned by Federal
administrative region (specifically the admin. regions delineated for HHS
operations -- e.g., NY / Philly / Atlanta / KC / etc.).
DE: This is a group number. It denotes a subset of a "block". The groups
are not issued in strict sequence. They are issued by odd number 1-9, then
by even numbers (10?-98?), then by even (00?-08?), then by odd again (11?-
99?) NOTE: the question marks mean I don't recall the exact "breaks", but
the general ordering given is correct.
FGHI: This is the individual number. Originally, there doesn't seem to have
been any particular issuance sequence in mind -- I assume they were simply
assigned sequentially. As of the mid-80's, these last 4 digits were assigned
by the SSA central office (Baltimore) and relayed back to the local office
where the application for a SSN was filed. The local office didn't (and
couldn't) know what the number was to be until notified by central office.
NOTES:
The block/group combo can tell one the region and locality WHERE THE
APPLICATION FOR AN SSN WAS FILED. There is no requirement that you file in
your hometown, home state, or whatever. In fact, foreign workers must file
for SSNs (to report taxes on US wages), and they do so wherever. This also
tells you the region and locality WHERE THE SSN WAS ISSUED. That's it. I
am not sure whether the granularity of group numbers could narrow it down
to district or precise office.
The operations manuals for SSA contain tables showing the regions, block/group
numbers, and dates. This enables SSA employees to know in which region and
by which (rough) date a block/group combo was issued. This info is used to
determine (with, or in the absence of, other data) length of residence in the
US for certain types of benefits SSA administers. There is no means for
verifying a whole number locally except a wire query to regional or central
office.
Since the 30's, there have been occasions when certain block and/or group
sets have been set aside for particular uses. (As best I recall...) the
700 series was originally assigned to RRB (Railroad Retirement Board) pensioners
, who were covered by a pre-existing, non-SSA pension system. The 900 series
was used for aliens working in the USA. I think a certain series (part of the
700 block???) has been used to denote Black Lung beneficiaries and/or their
dependents (I could be wrong on this).
I am an example of how far off this system could be. My hometown (Bristol,
Tenn. / Va.) straddles a state line. I grew up on the TN side; the SSA
office was on the VA side. TN is in the Atlanta HHS Fed. region, and VA is
in the Mid-Atlantic region. As a result, I got a Mid-Atlantic-assigned
SSN, even though I resided in the Atlanta region.
At the time I left SSA, they were getting concerned about SSNs and security.
The reason I remember even this much about a subject within my expected
range of knowledge (but not my daily activities) is that I attended security
training shortly before I left SSA. I was told (both in initial and follow-up
training) that the idea of checksum or other "validation checks" for the
numbers had in fact been brought up back at the beginning, but it was decided
such features didn't seem too American, and they were not in fact implemented.
PROBLEMS:
*Yes, the series is running out.
*No, there was no consistent and comprehensive tracking of deaths. As a
result, there is technically no coherent way of knowing when an SSN is
available for re-use. This deficiency mainly applies to the early days.
*In the 1950's (??) a wallet manufacturer (Prince Gardner??) put a dummy
specimen SS card in a line of billfolds (just for display). An unbelievably
large number of people used the dummy cards (and the number upon it) for
years. At the time I left SSA, there were still earnings being reported to
the "billfold" number, and huges amounts of time and effort had been expended
over the years in sorting out all the different peoples' earnings reported
to this one bogus number.
*People appropriate, take, steal, fabricate, etc., SSNs all the time. I have
seen cases where mentation-challenged folks have literally taken a parent's
or relative's SS card at their death and begun using it, thinking it somehow
inheritable.
*Between the mid-70s and the mid-80s the procedures for filing for SSNs got a
lot stiffer. The biggest fraud case I ever nailed was a guy who (after
defrauding SSA for several years, then losing his ill-gotten checks...) came
right back in under a close-but-different variant of one of his pseudonyms
and started right out again -- SSN, disability benefits, etc... Strange
thing was I believed he was the same guy from the start, but the SSN process
gave the benefit of the doubt to those who could explain away lack of ID and
evidence. He was a good liar, and I had to let him get a new SSN. Once
that hurdle was passed, he went on to disability benefits, and managed to
rack up some 2 years' worth of various bennies for himself and the family
before the slow fraud investigation process allowed us to shut him down
again. The procedures were tightened up sufficiently that by 1985, he would
not have had the benefit of the doubt.
*(Personal note) I think it was in 1985 that the 600 series was opened and
assigned to California (where else?) -- I was wondering if and when they
would issue 600-60-0006: "Six hundred _and_ sixty _and_ six" -- the actual
phrasing of the "Number of the Beast" in Revelations (for all you urban
legend/conspiracy buffs.... ;-) )
Well, anyway --- that's all I remember.
-- Randy
Randall Whitaker, Informationsbehandling / ADB
Umea University, 901 87 Umea Sweden rwhit@cs.umu.se
PS. None of this info is secrect, classified, or otherwise unavailable. You
have the right to enquire at any SSA office about this stuff, and they are
required to inform you. One of the things most surprising about my tenure
in the bureaucracy was the degree to which people didn't bother to either
check out or question how things worked.....
------------------------------
From: "David H. Close" <dhclose@cco.caltech.edu>
Subject: Re: Caller ID decision
Organization: California Institute of Technology, Pasadena
Date: Mon, 6 Jul 1992 21:39:31 GMT
Has anyone else commented on the general availability of ANI versus the
general unavailability of CLID? If you can afford a T1 link and an 800
number, there is no privacy issue mentioned when you get ANI from your
carrier. The caller is usually totally unaware. Its only the analog
customer with limited (home, small business) needs who faces the big
bruhaha over alleged "privacy". As someone else mentioned, privacy isn't
the issue, anonimity (sp?) is. But another, very real, issue is the
discrimination against smaller users who can't get the service which is
readily available today to large companies.
--
Dave Close, dhclose@alumni.caltech.edu, BS'66 Ec
Page House rules!
------------------------------
From: Kai Rannenberg <kara@cs.tu-berlin.de>
Subject: Information Technology Security Evaluation Manual (ITSEM) V0.2
Organization: Technical University of Berlin, Germany
Date: Tue, 7 Jul 1992 18:08:23 GMT
Hallo,
the Data Protection & Data Security Task Force of the German Gesellschaft fuer
Informatik (GI) has again published a "Statement of Observations" concerning
the IT Security Evaluation initiative driven by the Commission of the
European Communities.
This time the statement had to be made on the Information Technology
Security Evaluation Manual (ITSEM) in its current Version 0.2.
The ITSEM shall give help to evaluators and sponsors working with the
Information Technology Security Evaluation Criteria (ITSEC) and
therefore are related quite closely to them. ITSEC V1.2 was subject of
a "Statement of Observations" published by the GI Task Force in February 1992.
Discussion of Criticism on ITSEM V0.2 shall take place in Brussels
(Belgium) from September 8th to September 10th 1992.
Observations, criticism and proposals on ITSEM V0.2 concentrate on
the following issues:
(1) Lack of Correction of ITSEC problems
(2) ITSEC needs much deeper and therefore more improvements than
admitted in chapter 1.5.
(3) Who oversees the Certification Bodies?
(4) Several Classes of potential attackers are not covered.
(5) Threats can not be enumerated and must be specified the other
way round.
(6) The discrimination between strength of mechanisms in only 3 classes
(basic, medium or high) is very poor and not adequate.
(7) Requirements for Tools and Techniques are missing.
The full statement follows.
Best wishes
Kai
------------------------- cut here -------------------------------------
Statement of Observations concerning the Information Technology Security
Evaluation Manual (ITSEM) V0.2
Data Protection and Data Security Task Force of the German Society for
Informatics
(Praesidiumsarbeitskreis Datenschutz und Datensicherung der Gesellschaft
fuer Informatik)
June 16, 1992
The German Society for Informatics (GI) with its more than 18 000 members
is the largest German association of professionals working in information
technology (IT). As its highest board concerned with data protection and
data security, we want to bring the following observations and
recommendations to the attention of the Commission of the European
Communities as the sponsor of ITSEM, the politicians, all professionals
working in the field of informatics and especially those engaged in the
further standardization of "Evaluation Criteria for IT Security" within
ISO/IEC JTC1/SC27 and last but not least society at large.
The Information Technology Security Evaluation Criteria (ITSEC) and the
accompanying Evaluation Manual (ITSEM) are intended to have a significant
influence on security issues, primarily in a technical sense. If they gain
it, due to the socio-technological nature of IT systems, they will also
have a significant influence on organizational structures. Due to the
pervasive nature of IT, the everyday-life of each individual living in the
European Community will be affected. This causes significant changes in
social structures. If IT systems are insecure, society at large is at risk.
If they are structured in an Orwellian way, they are a threat to democracy.
Therefore, the points summarized in the following are of upmost concern to
us.
Observations
Except for the first observation, which concerns ITSEM as a whole, the
other observations are in a sequence which reflects the ordering of the
referenced Paragraphs within ITSEM.
1. Lack of correction of ITSEC problems
Except in the area of re-evaluation and re-use of evaluation results, ITSEM
V0.2 does not even try to overcome the deficits of ITSEC V1.2. This means
that all points raised on ITSEC V1.2 in our Statement of Observations of
Feb. 24, 1992, are still valid except those in the respective Chapter 5. We
are not only waiting for an answer regarding the contents of our
statements, but we are waiting for the urgent needs of an information
society being really and thoroughly addressed by the ITSEC/ITSEM actors.
Except for its Chapters 8 and 9, ITSEM V0.2 is a missed opportunity in this
respect.
2. ITSEC needs much deeper and therefore more improvements than admitted in
ITSEM 1.5
There are much more severe deficits in ITSEC V1.2 than those admitted here.
Given the public Statements of Observations (e.g. our Statement of Feb. 24,
1992, and the even more detailed Statement of Andreas Pfitzmann of Nov. 29,
1991), 1.5 of ITSEM V0.2 raises severe concerns whether its authors are
capable and willing first to understand and thereafter to work on
overcoming these deficits. Therefore, the CEC should sponsor the
development of alternative proposals and evaluation experiences for future
versions of ITSEC and ITSEM.
3. Who oversees the Certification Bodies?
It is not only necessary to oversee evaluations (and thereby ITSEFs) as
noted in 1.16 of ITSEM V0.2, but Certification Bodies as well. For inside
the European Community, an appropriate institution might be the European
Parliament.
4. Several classes of potential attackers are not covered
As ITSEC, ITSEM does not by far consider all potential attackers. E.g.,
the designers of the Target of Evaluation (TOE) might implant a universal
Trojan Horse, the designers of the tools used in generating (and analysing)
the TOE might implant a transitive Trojan Horse, and so forth, as noted
already in a Statement of Observations to ITSEC V1.0. In ITSEM, this
deficit becomes even more explicit:
In 3.34, it is completely forgotten that the designers of the TOE know
details which are not in the public domain and which they did not obtain
maliciously.
In 4.192 b) and c) the following persons have to be added:
Designers of the TOE;
Designers of tools used to build the TOE;
Designers of tools used to build tools used to build the TOE;
and so forth.
This has to be reflected throughout the rest of ITSEM.
5. Threats cannot be enumerated and must be specified the other way round
As is well known both within the fault tolerant computing and within the
security community, neither errors nor threats can be enumerated with a
reasonable confidence in completeness. Therefore, errors and threats must
be specified the other way round, i.e. it has to be stated what properties
of which components and subsystems are assumed.
If necessary, the assumptions have to be qualified:
1) Under which circumstances are they considered to be true?
2) In distributed systems, it has to be stated: For whom are they
considered to be true? (In other words: Who has to rely on them?) In
general, in distributed systems, the one who has to rely on an assumption
has to be the one who can make it true.
Within their computing capabilities, components and subsystems with assumed
properties may behave arbitrarily as long as they do not thereby violate
these explicitly stated assumptions. All other components and subsystems
may behave arbitrarily within their computing capabilities. For a TOE to be
considered secure, all its security properties have to be deduced from
these assumptions. If these assumptions are reasonably weak, this deduction
gives the best attainable confidence in the security of the TOE. Therefore,
formulations like "... countering the threats enumerated in the security
target." (ITSEM V0.2 3.39) and "... covers all threats enumerated in the
security target." (ITSEM V0.2 10.23) are not state of the art and
misleading to users of ITSEM.
6. The discrimination between strengths of mechanisms in only three classes
(basic, medium or high) is very poor and not adequate.
ITSEM 4.193 is a clear indication that the discrimination between
strengths of mechanisms in only three classes (basic, medium or high) is
very poor and not adequate. By comparing the statements given in b), d),
and f) it is evident that resistance to completely different severe attacks
is mapped to the same class "high".
7. Requirements for Tools and Techniques are missing
In Chapter 7 of ITSEM V0.2, essential requirements on tools and techniques
are missing. In part, this is due to the fact that ITSEC does not state, as
in [Criteria for the Evaluation of Trustworthiness of Information
Technology (IT) Systems, ISBN 3-88784-200-6; German Information Security
Agency, 1989, p. 53], that evaluation levels beyond E6 are possible, very
desirable, and might be defined in the future.
One reason for this and the reason why essential requirements in Chapter 7
of ITSEM are missing is that there are transitive Trojan Horses, cf. the
Turing award lecture by [Ken Thompson, Reflections on Trusting Trust;
Communications of the ACM 27/8 (1984) 761-763]. These transitive Trojan
Horses can spread through the used tools into the TOE. If the Trojan Horses
are universal ones [D. Denning: Commutative Filters for Reducing Inference
Threats in Multilevel Database Systems; Proc. 1985 IEEE Symp. on Security
and Privacy, April 1985, Oakland, Computer Society, 134-146], this threat
becomes especially severe.
Examples for evaluation levels beyond E6 are
Level E7: Verified design history of all tools used to develop the TOE.
Level E8: Verified design history of all tools used to develop tools used
to develop the TOE.
and so forth.
The ultimate level would require that all (recursive definition!) used
tools have verified design, i.e. you need some form of secure bootstrap in
generating these tools.
The implictions for Chapter 7 of ITSEM are obvious: Tools and Techniques
(T&Ts) must either have completely diverse design history (if possible
between each other and most important in any case between the TOE and
any T&T) or must be checked by the evaluator thoroughly. Therefore, in
A.116 b) (or at least in the corresponding Paragraph on the highest
evaluation level to be defined) it has to be stated that the used tools
themselves have to be checked and how this shall be done thoroughly. In
A.119 (or at least in the corresponding Paragraph on the highest
evaluation level to be defined), the source code of all compilers used has
to be checked.
---------------------------------------
Kai Rannenberg Technische Universitaet Berlin Informatics Department
E-Mail: | Snail Mail:
|
kara@cs.tu-berlin.de | Sekretariat FR 5-10
Phone: (+49 30) 314-73499 | Franklinstr. 28/29
Fax: (+49 30) 314-24891 | D-W-1000 Berlin 10, Germany
------------------------------
From: johnson@spectra.com (boyd johnson)
Subject: Re: SSNs and Social Insurance Numbers
Organization: Spectragraphics Corporation
Date: Tue, 7 Jul 92 20:12:16 GMT
In article <comp-privacy1.56.5@pica.army.mil> bear@tigger.cs.Colorado.EDU (Bear Giles) writes:
>In article <comp-privacy1.55.6@pica.army.mil> flint@gistdev.gist.com (Flint Pellett) writes:
>>
>>If anyone really knows about SSN's, I'd love to know what plans
>>exist for them in the future. They only have 9 digits, and since
>>we have 250,000,000 people (or more-- I haven't kept track)
>>currently alive in this country, that indicates that most likely
>>20 to 25% of the available numbers are in use by persons currently
>>living. I would guess that within the next 100 years that we'll
>>run out of 9 digit numbers that haven't already been used: do they
>>plan on re-using the numbers of deceased people, (a big potential
>>problem, I would think, since estates often live on a long time
>>after the person), or are they going to go to 10 digits and break
>>computer programs all over the place?
A few years ago they went to 9 digit Zip codes and California went from
6 to 7 digit license plates. The 10 or 11 digit SSN would cause
similar database problems, but it could be fairly easily remedied.
>If they add one digit, they'll certainly add a second (for a checksum
>since SSNs are used so widely now).
>
>But you make two interesting assumptions: first, that the U.S.
>Government will care about the fact that other organizations use
>the SSN as an identifier (SSN records could probably be freed within
>a few years of person's death); and second that the new number will
>only be used in the U.S. With a North American Free Trade union
>you could make a good point for a NAFTU-SSN... if not a global SSN
>(since it is likely people will change countries much more in the
>future).
Hmmm...interesting:
REV 13:16 And he causeth all, both small and great, rich and poor, free and
bond, to receive a mark in their right hand, or in their foreheads:
REV 13:17 And that no man might buy or sell, save he that had the mark, or the
name of the beast, or the number of his name.
REV 13:18 Here is wisdom. Let him that hath understanding count the number
of the beast: for it is the number of a man; and his number is Six hundred
threescore and six.
Any guesses as to what the SSN checksum would add up to?
--
======== Boyd Johnson nosc!spectra.com!johnson San Diego, Ca. ========
------------------------------
End of Computer Privacy Digest V1 #059
******************************