Newsgroups: sci.crypt,comp.security.misc From: pgut001@cs.auckland.ac.nz (Peter Gutmann) Subject: ISO security standards generation Date: 17 Jun 1996 00:54:58 GMT Message-ID: <4q2ad2$2n7@net.auckland.ac.nz> When commercial organizations look for encryption or security products, they frequently know very little about anything to do with computer security - the approach can be summarized as something like "We want to do Internet commerce because that's where the money and the suckers are. Give us a large order of security, and a side order of encryption, to go". A typical response to the specification for an encryption product runs along the lines of "What are all these algorithms? IDEA, what's that? Safer? Blowfish? What are all these encryption modes, ECB, CFB, CBC? Why do we need this secure key exchange thing, what's wrong with just faxing them a new key every day, or sending it in email?" (this really happened!). And so on. Unfortunately saying something like "Well, this product follows some guidelines set out in an IETF draft which expired last year and some ideas I got from reading Applied Cryptography" doesn't really cut it. These people want standards, preferably ISO standards. Now this is a bit of a problem, since the ISO spontaneously decided some years ago, all by itself, with no outside influence applied, not to standardise crypto algorithms. There are some security standards, but they're either so baroque that noone uses them, or change every few weeks or whenever the appropriate subcommittee which is arguing about them meets next, whichever comes sooner. Unfortunately this presents anyone who needs to list the standards their crypto software complies with with a bit of a quandary. However, there is a solution. First, it should be observed that noone who makes decisions about using a particular crypto package ever reads ISO standards (or any other standard for that matter. If it's not in PC Week, it's not worth reading). Second, there are so many different ISO standards, revisions of standards, working drafts, updates, draft standards, committee drafts, and other strange mutations around, most of which any mortal can never get their hands on anyway, that noone will ever be able to check whether some standard you claim compliance with really exists ("Oh, you want ISO 10167:1994, not 10167:1992 (which is completely different) or 10167:1988 (which is different again). No, that's part 4, not part 2. And make sure you get the final standard, not the committee draft, or the final draft. And get draft amendments 1 and 6, and final amendment 4 as well, because they're important"). If they do decide to follow up on acquiring the standards, a simple trick such as mentioning the fact that the cost of buying them all will be greater than the projected revenue for their department for the next 5 years will discourage any such efforts. If all else fails, just include the following magic phrase at the start of your list of standards: In order to make use of this document, a thorough understanding of ISO 8824:1993 and ISO 8825:1993 is assumed. Once they see what ISO 8824 is, they won't even bother trying to find any other standards you refer to (in fact they may leave the profession entirely and take up gardening instead). So now you have your method for presenting the standards. This doesn't, however, solve the problem that there aren't many useful standards available which cover what you'll be doing. To help you, we have created the ISO Security Standards Generator (Mark I), whose operation is presented below. To use it, you'll need some multi-sided dice (4-sided (d4), 6-sided (d6), and 10-sided (d10), as defined in ISO/CD 14671:1992, Part 4, Annex B). The ISO Security Standards Generator (Mark I) Security-related standards don't really start until about 8000, and then there's a whole raft of them after about 11000. The following algorithm takes this into account. Step 1: Basic standard determination Roll 1d4. Result = 1: The standard will be from 8000-11000. Goto Step 2. Result = 2-4: The standard will be above 11000. Goto Step 3. Step 2: Standard number determination, 8000-11000. Roll 1d6/2 for the high digit, 3d10 for the low digit. Add the result to 7000. This is the standard number. Roll 1d6 and add 1986. This is the year. Goto Step 4. Step 3: Standard number determination, 11000+. Roll 1d6/2 for the high digit, 3d10 for the low digit. Add the result to 10000. This is the standard number. Roll 1d6 and add 1991. This is the year. Step 4: Standard part number determination. Roll 1d10. Result = 1-5: This is the part number. Result = 6-0: The standard contains only one part. Step 5: Status determination. Roll 1d4. Result = 1-2: Full standard Result = 3: CD (committee draft) Result = 4: DIS (draft international standard) Example: Step 1, result = 2, goto step 3. Step 3, result = 1, 6, 4, 1, number = 11641. result = 2, year = 1993 Step 4, result = 4, part = 4. Step 5, result = 4, DIS. Thus this security standard is ISO/DIS 11641-4:1994. OK, now that you've got your standard number and year, you need to name it. Since the ISO naming convention changes every few years, you've got a wide range of titles to choose from, and can use this to confuse people who try to find "your" standard. Step 6: Category selection. Roll 1d12. 1 = Banking and Related Financial Services 2 = Banking - Key Management (Wholesale) 3 = Banking - Secure Data Exchange 4 = Banking - System/Security Management 5 = Data Cryptographic Techniques 6 = Financial Institution Encryption 7 = Financial Institution Key Management (Wholesale) 8 = Financial Institution Retail Key Management 9 = Information Processing - Data Encipherment 10 = Information Technology - Open Systems Interconnection 11 = Information Technology - Security Frameworks in Open Systems 12 = Information Technology - Security Techniques Note that option 10 can be used in the same way as ISO 8824:1993 by including a requirement that all of OSI be understood before this particular standard is used. However this may contravene some sections of the Geneva Convention, particularly those covering cruel and unusual punishment and inhumane treatment of others. On the other hand there may be exemptions allowing this to be applied to marketing people. Check this with a lawyer before applying it. Step 7: Finally, you need to decide on the rest of the name for your standard. Since you'll need to tailor this to your particular application or algorithm, you'll have to manually chose the name rather than selecting it from a table. Some recommended names are: Specification of Algorithm XXX Modes of Operation [of Algorithm XXX] Digital Signature Message Authentication Code Key Management by Means of XXX Approved Algorithms for XXX [: YYY Algorithm] Entity Authentication This should cover most eventualities, or should at least give you an idea of the type of name to aim for. Taking our previous example of ISO/DIS 11641-4:1994 lets say we want to apply this to the Safer-SK encryption algorithm. Rolling 1d12 we get 4, "Banking - System/Security Management". The rest of the title is quite obviously "Specification of Algorithm Safer-SK". Thus in our sales literature we would state: This product employs the Safer-SK encryption algorithm as specified in ISO/DIS 11641-4:1994, Banking - System/Security Management - Specification of Algorithm Safer-SK. In some cases you may not be able to find a useful classification for the standard your product complies to (for example you may always zeroise memory after use, which isn't really a crypto algorithm or key exchange or authentication technique). In this case a general guide is to class it under one of the generic "Banking - System/Security Management" or "Information Technology - Security Techniques" names and then think up the appropriate title. If you want to give your standard that extra polish, cross-reference it to an ITU standard by adding "ITU-T X." to the ISO standard number. Finally, if you're really worried that someone might question a particular standard, claim that your algorithm or technique is "currently being considered by ISO/IEC JTC1/SC<18 or 21 or 27>/WG for future standardisation". Noone will ever be able to verify this, or be terribly surprised if the referenced standard never appears. All flames sent in response to this message will be ignored unless they conform to (hang on a minute)... ISO/CD 12675-2:1994 and the latest DAM for ISO/DIS 10156:1991. Peter.