аЯрЁБс>ўџ ўџџџ‹ŒџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџьЅСM №ПЧlbjbjт=т= %ф€W€WЧhџџџџџџlІІІІІІІК    ,К’ ЖX X X X X X X X        $H h 7 ІX X X X X 7 X ІІX X L X X X X ІX ІX  X X  X ЎX  :š cІІ X L €и9ј.РКZ X §  b 0’  tX t X ККІІІІйPossibilities for Covert Write Down Detection via Null Differential, Marked Money Tests M.S. Jaffe Department of Electrical Engineering and Computer Science Embry-Riddle Aeronautical University Prescott, AZ, 86301 ABSTRACT: There is a fundamentally intractable conflict between certain military command and control systems' needs for commercial-off-the-shelf (COTS) software and conventional Bell-LaPadula [1] based security policies. In many contexts, the conflict may not be important, but there is at least one important operational environment where its impact is significant and an alternative approach might be worth what will clearly involve some degree of increased risk. This paper derives the essential elements of one such alternative approach, indicates why it may be the only possible approach to this one particular problem under a limited but important set of circumstances, and identifies the key characteristics of the new features that would need to be developed. 1. INTRODUCTION Two conflicting dictates help drive the INFOSEC architecture of many military command and control systems that are devoted to operational planning and the dissemination of human-readable plans and support data. In addition to the obvious need to protect sensitive information from inadvertent disclosure, there is an increasing need to make use of commercial-off-the-shelf (COTS) applications software for reasons of both operator efficiency and economies of development. The Navy's new IT-21 initiative, for example, "is a fleet-driven reprioritization of command, control, communications, and intelligence (C4I) programs of record to accelerate the transition to a PC-based tactical/tactical support warfighting network. ... Microsoft Office 97 is designated as the standard fleet office automation software."[2] There are several major disadvantages to such COTS software in military operations, however. Two to be discussed here are: 1. Many of these packages, such as Microsoft Office 97, are not compatible with any operating systems certified at the Orange Book B levels [3] necessary for multi-level security (MLS). 2. Much potentially valuable COTS applications software is not trusted and hence cannot be used to sanitize and then downgrade operational documentation. The second factor is perhaps the more significant, since operationally acceptable workarounds for the first would be facilitated by a solution to the second. The operational utility of COTS-based MLS sanitization and downgrade is obvious. A systems high enclave operating, for example, at the Secret level could produce a COTS document classified Secret on the basis of one paragraph, the rest of the document being at the Confidential level. If the enclave wished to export a Confidential version of the document, an operator could open the Secret document, delete the Secret paragraph, and export the result as Confidential. The product would thus have been sanitized and downgraded by the COTS package. The problem, of course, is that software that can downgrade must be trusted and the COTS package is not trusted. As a result, such COTS software today is generally limited to documents exchanged only within a system high security boundary; MLS enclave inter-operability via high productivity COTS-based documents remains problematic. The requirement to trust downgrading software is critical. In some versions of commercial word processing packages, deleted material is not always physically deleted from the document when the document is saved. It is merely marked somehow as having been deleted and not displayed the next time the document is opened. That is obviously not sufficient for sanitizing classified material for export and these features of a COTS package must be disabled before further problems can even be addressed. The invisible retention of apparently deleted material is far from the real problem, however. It's merely illustrative. A tougher problem is the possibility for undetected insertion operations by a malicious Trojan Horse. Consider the same basic scenario of a system-high enclave operator at the Secret level trying to produce a Confidential document for export even without sanitization --- in other words, composing from scratch, in a Secret system high environment, a document intended for export at the Confidential level. Given that the TCB in the Secret enclave is Orange Book C2, which is all that the Yellow Book [4] requires for system high operations, what guarantee is there that Trojan Horse code there does not maliciously insert invisible Secret material into the ostensibly Confidential document --- thus achieving a covert write down? Obviously there is no guarantee possible beyond the normal C2 trust levels --- which are not sufficient for multi-level secure interoperability (e.g., exporting Confidential material to a Confidential system high enclave from a Secret system high enclave). All current solutions to this problem (e.g., system high federations with huge security boundaries, air gaps, or text-only export with trusted manual review) involve significant operational shortcomings. So there is a real conflict between the need for multi-level secure interoperability and the operators' wish for familiar, user-friendly, productive COTS packages that, unfortunately, are not currently trusted nor compatible with Orange book B2 or better operating systems. This conflict is intractable. It is fundamental to the nature of Bell-LaPadula security policies: Software that can downgrade must be trusted to do so safely. Designers of military planning systems must thus either: Develop expensive, trusted equivalents to inexpensive but untrusted COTS applications packages; or Force their operators to retrain from their familiar home or classroom desktops to use much less capable, less productive custom tools and procedures; or Accept significant operational constraints on digital interoperability; or Extend the system high boundary to encompass entire federations of enclaves that really should inter-operate in compartmented or multi-level modes; or Accept what is often an unacceptable level of risk of compromise. (Experience with such recent infowar exercises as Eligible Receiver [5] should heighten concerns in this area.) This is a dismal set of choices. As the Navy's IT-21 initiative [op cit] makes clear, options 1 and 2 are being rejected. Option 3 precludes MLS interoperability. There is another possibility, however, which, although riskier than the conventional Orange Book approach to INFOSEC, may nonetheless be less risky than alternatives 4 and 5, above in circumstances where MLS interoperability is really required . 2. A POSSIBLE ALTERNATIVE 2.1 Rationale and summary of the approach. A Bell-LaPadula policy is based on the necessary assumption that a covert write down violates an MLS system's confidentiality policy. Under conventional circumstances that is true. If a system has multiple levels of data stored within while it is simultaneously interacting with multiple levels of users within its boundary, the write down immediately makes improperly labeled information accessible to unauthorized users. So prevention of covert write down is the only possibility. But an MLS military system consisting of a federation of system high enclaves has a slight advantage: unauthorized access to the improperly labeled information cannot occur until it is exported beyond the boundary of the system high enclave. That extra period of time between the actual write down and the policy-violating export provides an opportunity to detect that a Trojan Horse has been operating, i.e., performing covert write downs. Ideally, one would like a method of detecting any covert write down but such a technique is not currently known and, for a variety of reasons, seems unlikely to ever be developed. But under some circumstances it might be possible to offer probabilistic assurance that the operations of a Trojan Horse could be detected before it succeeded in exporting improperly labeled documents. If so, the decision to permit the deployment of such a system would return to issues of risk versus utility that accrediting authorities are chartered to deal with. The probabilistic detection strategy is based on the possibility of a "marked money" test which might detect some COTS-based write down operations by a Trojan Horse. Then the question would shift to one of the degree of analytic or empirical predictability in providing a probabilistic assessment of success in a given operational environment against a given level of sophistication in the threat. Many of these issues are still under investigation and will not be reported on here in any generality. The focus here will be on the nature of the required characteristics of the essential but as yet unknown marked money signatures (and the reasons for thinking they might exist) and the circumstances under which they might usefully be employed. It is certainly not claimed that operational solutions are close or even likely --- only that the possibility should not be totally dismissed and that the possible payoff makes further work worthwhile. 2.2 The Environment and the Goal. The key features of a marked money testing include: 1. A set of COTS workstations requiring a COTS operating system certified no higher than Orange Book C2 or equivalent. 2. One or more productivity-enhancing but untrusted COTS packages to be used by the enclave's human operators to prepare operational products (documents) for export to a lower classification enclave. 3. A trusted MLS guard box controlling the export point. The workstations constitute a system high enclave and appear to their operators as normal, high productivity COTS tools much like the ones they probably have at home or have used in previous, unclassified assignments. It is the Guard box, or some other highly trusted processor, which will run the marked money tests to detect the presence of any operational Trojan Horse. These tests will not require the use of the COTS packages so the Guard OS (which must be trusted to the appropriate MLS level) would not have to be compatible with the COTS software. The custom software in the Guard box necessary for marked money tamper detection should be sufficiently simple as to permit trust at Orange Book levels adequate for true MLS export operations. The operational goal is to permit the COTS tools in the COTS workstations to prepare downgraded documents for export without extensive human-in-the-loop review of text at the Guard box. 2.3 Marked Money Testing and Cryptographic Seals. The goal of marked money testing is to detect the operations of a Trojan Horse prior to its achieving an export that would actually breach the system's confidentiality policy. (The recovery from such detection will be beyond the scope of this paper's discussion, which will focus only on the prospects for detection.) In the discussion that follows, it is assumed that the window of opportunity for a Trojan Horse's possibly undetected or covert write down can be confined to that period of time when a document has been opened for write access by a COTS application. Cryptographic message authentication codes (a.k.a. "seals") calculated by trusted software in a trusted environment (e.g., a Guard box) are one technique used to produce such an environment. In other words, the trusted association of a crypto seal with a document can guarantee, up to the mathematical strength of the seal, that a covert insertion attempt on that document will be detected unless it occurs when the document is "unsealed". (A document is unsealed after it has been modified and before its new seal is calculated.) The first of several key questions to be addressed, then, is, are there any circumstances where the defense could detect that a covert write down had been performed while a COTS-based product was unsealed? Then a defense might be based on developing "marked money" products and detecting that covert insertion had in fact occurred on them. It will then be necessary to address the question of the likelihood that a Trojan Horse would in fact attempt a covert insertion into the marked money product as opposed to other unsealed products where it could not be detected. Suppose there were some attribute of certain files (and certain operations on those files) such that the resultant attributes could be predicted in advance provided that no covert write down had occurred. Call such an attribute a marked-money signature. If the Trojan Horse performed a covert write down into such a product, the Guard box could detect it because of the defective signature. Thus a marked money test succeeds when the Trojan Horse makes the mistake of selecting the wrong file for covert insertion. Note that a crypto seal itself is unsuitable for use as a marked money signature since it is required to be much too strong --- it should not be possible to predict the value of a new seal merely from knowledge of the original seal and the operations to be performed during a marked money test. Such predictability would render the seal itself subject to crypto-analytic attack. But a weaker and hence more predictable marked money signature might, when used as above in combination with a stronger seal, still provide a useful Trojan Horse detection mechanism if the Trojan Horse did not know what signature was being used --- this last point, obviously, is going to require addressing the old and justifiably discredited "security by obscurity" argument again, but this time there will be a potential new twist. 2.4 Required Attributes for Signatures The simplest marked money signature (which won't work but will illustrate the direction to be taken) is identicality on null differential products. For example, suppose the Guard made a copy of a product which was then opened for write access at a normal workstation and then simply closed again (without actual intentional modification) and sent back to the Guard box which compared the previous version to the newer one. If they were not identically the same, a Trojan Horse might have been detected. In practice, unfortunately, this approach won't work at all --- there are several innocuous reasons why the old and the new version of such COTS documents might not match. This "open-and-shut" approach is also a poor choice since a smart enough Trojan Horse wouldn't attempt a covert insertion unless the document were in fact modified. But the basic idea is that a marked money test will be a null-differential test --- a series of operations intended to entice the Horse into believing that this product is "real" and hence a candidate for covert write down. The more sophisticated the hypothesized threat, the more elaborate the marked money deception would have to be. Ultimately, an acceptable taxonomy will need to be developed convincingly articulating an exhaustive list of the mechanisms by which a Trojan Horse might select victims for covert insertion. But such taxonomies are potentially feasible and preliminary indications are that, given the right marked money signatures, appropriate variants of marked money tests could succeed in "fooling" a broad range of Trojan Horses. Whether or not this partial coverage would be sufficient in any given environment would be a question for the accrediting authority. For the moment, we need to continue a search for appropriate signatures to detect the Trojan Horse within the "noise" of the COTS products. Length of the product is also unfortunately unacceptable as a marked money signature for two equally important reasons: 1. Experimental data shows that some COTS products would require the length signatures to permit huge deltas, on the order of kilobytes, much too large a covert bandwidth. 2. Length is too simple. It is not beyond the bounds of plausibility that a Trojan Horse could be sophisticated enough to cover its tracks by deleting information of the same size as that covertly inserted. So a good null differential marked money signature needs to be weaker (more predictable) than a seal but stronger than identicality or length differential. How much stronger will depend on suppositions about the sophistication of the Trojan Horses it's designed to catch. Is it a good idea to base a defense on suppositions about hypothesized digital threats? Not if there are any better alternatives available; but, as noted earlier, there don't appear to be. Before considering the likelihood of fooling a hypothesized Trojan Horse, there's one final attribute of a good marked money signature. It should be parameterizable, meaning that the Guard (which would be trusted) could randomly change the logic of the marked money signature. A Horse optimized to avoid detection by one signature would fail against another. Can such a family of signatures be developed? We need to look, but there are several potential avenues to explore. Although some preliminary attempts have not been promising, there seems no a priori reason why a search might not succeed and, as noted, the payoff could be quite high. 2.5 Sophistication of the Threat --- Its Susceptibility to Marked Money Testing One point in the defense's favor is that although the attacking Horse may be malicious, it need not necessarily be assumed to be initially diabolical. What follows is a revisit to the old "security by obscurity" argument, but with a special pleading: many of the factors which legitimately demolish a "security by obscurity" argument in the normal case may be shown to be much less relevant in the context of a military planning system designed from the beginning to protect itself. The signature calculation logic, for example, could be classified, which "normal" COTS security-by-obscurity features cannot, and would only be present in the trusted environment of the Guard where the COTS package containing the Horse cannot execute. (How trusted is the guard? Since it is not running COTS application software, as secure as current technologies permit --- B3 level operating systems for Guards are already available.) So consider the evolution of sophistication of a Trojan Horse. First, we can assume that the initial malicious logic must be embedded at the COTS "factory" and is present in all copies of the COTS products throughout the world. Various standard OPSEC precautions can insure this. So the initial operations by the Horse will be "blind" --- meaning that it must be autonomous. It cannot obtain additional information about the nature of the system it is attacking from an outside human "controller" (outside that system's security boundary) until after it succeeds in establishing a bi-directional covert channel to that controller. At the start of it's malicious lifetime, it must select targets for covert write down based on logic that was present when the Trojan Horse was created. (And if the planning system operates in the export-only mode, it will stay that way [autonomous] throughout its entire lifetime. Were the planning system to permit COTS product import as well as export the situation is far more dangerous but not necessarily hopeless even then --- incoming products could conceivably be used as the basis for marked money tests, for example.) In any case, if the initial Horse had no initial selection logic but selected insertion targets randomly, the odds of detection could be made arbitrarily high as the ratio of marked money operations to real operations was made arbitrarily high. With modern workstations, marked money tests might be run continuously in the background --- which raises the question of whether or not the Horse could have been programmed initially to detect that the insertions and deletions of a marked money test were being conducted by software rather than an actual operator. In the extreme case, depending on cost/risk analysis, an outboard keyboard/mouse simulator might be possible. The next case to be considered assumes that the Horse is initially more selective and is "triggered" into covert insertion somehow. Such triggers can only be data or time based (or some combination of both). Note that the data referred to is data in the target vehicle, not data elsewhere in the system. A Horse that waits to do anything at all until it sees the words "Top Secret", for example, still has to have a strategy for selecting a target. It might, for example, look for a document that included the word "Confidential". (Hoping to covertly insert Top Secret data into a document intended to be exported as Confidential.) It might further have been programmed not to do even that until February 1, 1999, for example. Here the defense gets a break. It is probably (all these arguments are "probably", based on sophistication of the assumed threat in the initial, "blind" Horse) sufficient to consider only ASCII content triggers. In other words, the Horse looks for documents containing text containing certain key "triggering" words (e.g., "Confidential"). Binary data (drawings, images, sounds, maps, etc) would seem too difficult for an attacker to predict the precise pattern that indicates an increased likelihood of export for a product. Note: If the Horse is inserting "randomly" into such binary products, "normal" marked money tests would work as discussed above. So the question then would be, how would the defense detect a Horse that was waiting for an ASCII text or time based "trigger" in the document to cue its covert insertion. If it were "pure" time (i.e., the Horse waited until the midnight on 28 Feb, 1999, for example), running normal marked money tests at a workstation with an artificially advanced clock reduces this case back to normal. What's left is the content based cue --- e.g., the Horse looks for a target containing the word "Confidential". For this case, it seems possible to consider developing "dynamic dictionary" based marked money tests. The defense continually scans its products to construct a dictionary of ASCII words and constructs marked money tests that include all words in the dictionary. It should further be possible to arrange logic in the Guard that would permit no document to be exported that contained a word not in the lexicon of the dictionary tests. In other words, if an operator developed a document containing new possible triggers, they would have to be used in marked money tests prior to export of the originating document. Can this scheme be beaten by a sufficiently "smart" Horse? Surely. A Horse could look for phrases, rather than just single words, for example. The question again becomes one of cost versus risk. Can the attacker predict entire phrases that will be entered manually by non-cooperating users? (There are much simpler ways then Trojan Horses for an attacker to breach the confidentiality of a system where one or more operators are co-operating with the attacker.) In general, the more general the trigger, the more likely a dictionary based marked money defense will work; while the more specific the trigger, the less faith the attacker could have in its actual invocation at a useful time. Again, this argument does not work at all if two way exchange of COTS products is permitted. If the external attacker can prepare documents containing an arbitrary trigger phrase such as "climb Mount Whitney" and arrange its import into the system under attack. (But, as noted earlier, if the construction of marked money tests were automatable, such imports could be used to help entice a Horse into a detectable indiscretion.) The point is that an initial, blind Horse is vulnerable. It must not only identify the more highly classified information for covert export on its own, it must similarly find a target vehicle without human assistance and make a successful covert insertion only when the target is unsealed. If it does not look at the contents of the possible target vehicles, the defense's likelihood of detection can probably be made arbitrarily high. So the Horse must search for trigger conditions --- either in the content of the target or the actions of the operators or the clock (or some combination of the above). Particularly in export-only systems, the continual construction and employment of new, dictionary based marked money tests can increase the probability of detection significantly. 3. SUMMARY, STATUS, AND FURTHER WORK Because the conflict described earlier is intractable, any alternative will have to depart from the prevention-based approach of the Orange Book. What cannot be prevented (covert write down), may, under certain circumstances, be probabilistically detected before harm is done. In addition to more or less standard architectural features (e.g., a Guard box and cryptographic seals) there are two new factors to be considered or developed: (1) Suitable marked money signatures, weaker, but more predictable than cryptographic seals, and (2) A complete characterization of types of marked money tests versus the types of triggers they would detect. Several candidate signatures are under investigation, but some of the more useful COTS products are very "noisy" in terms of null-differential tests. One option is to ask COTS vendors to eventually eliminate or at least reduce null differential noise. There are other alternatives under investigation. At the moment, no acceptable signatures have been found suitable for the full range of COTS products that might be desired; but there seems to be no theoretical barriers to such techniques providing potentially worthwhile increases in practical protection. And, as noted earlier, if MLS interoperability involving COTS-based documents is the goal, the alternatives remain quite dismal. REFERENCES 1. Bell, D.E, and LaPadula, L.J., Secure Computer Systems: Mathematical Foundations and Models, Mitre Report M74-244, Mitre Corporation, 1973. 2. Secure Windows NT Installation and Configuration Guide: Windows NT for Navy IT-21, Department of the Navy, Space and Naval Warfare Systems Command, Naval Information Systems Security Office, PMW 161, Nov,ember 1997. 3. Department of Defense Trusted Computer System Evaluation Criteria [aka the Orange Book], DoD 5200.28-STD, December 1985. 4. Technical rationale behind CSC-STD-003-85: Computer Security Requirements, Guidance for Applying the department of Defense Trusted Computer System Evaluation Criteria in Specific Environments [aka the Yellow Book], CSC-STD-004-85, 25 June 1985. 5. Gertz, B., Computer hackers could disable military; System compromised in secret exercises, The Washington Times, April 16, 1998. XитмэяѕI’d"g"Щ$Ю$(6(“-Ф-b2e2Ž9Е9aGБGуc dJiViWiЙiЭiьi>j?j@jk k!k1klll,lœlБlЦlЧlі№ч№ч№о№ч№о№о№ч№ч№о№ч№ч№ч№ч№мзмзмзмзмзмзмзмзм№ 6]hh6CJ]aJh5CJ\aJh CJaJh5CJ \aJ h.XcТжзилмьэš T ю Ž   )*љљљљљііііљљіччіірійірЮй „о„ђў1$^„о`„ђў„Т1$`„Т„h1$`„h Ц8„*„˜ў1$^„*`„˜ў1$$1$a$Чl§}bњ­FIde’[$\$((8(l(у(Ћ)ц)’-“-Ч-2яяяяяььццьььпьььааЩьььь„а1$^„а Ц8„8„˜ў1$^„8`„˜ў„Т1$`„Т$1$a$1$ & F Цhа„а1$^„а22U4V49Ž9Е9== A AƒA1BCдDеD`GaGБGOKPKсOтO…R†RљWњWќѕќѕќќќќѕќюууќќѕќќќќѕќюќѕќ „v„ђў1$^„v`„ђў„h1$`„h„Т1$`„Т1$њW`\a\Ь`Э`Ю`уcфc d dУe$f“fJiKiViWiшiХjCk=lУlФlХlЦlјѕюѕѕјшшшѕннѕшшшѕѕѕѕѕввв „„ђў1$^„`„ђў „а„˜ў1$^„а`„˜ў$1$a$„h1$`„h1$„Т1$`„ТЦlЧlќ1$#0PАа/ Ар=!А"А# $ %А i6@ёџ6 Normal7$8$_HmH sH tH <A@ђџЁ< Default Paragraph FontЧhфџџџџXcТжзилмьэšTюŽ  )*}bњ­FIde’[ \ $$8$l$у$Ћ%ц%’)“)Ч)..U0V05Ž5Е599 = =ƒ=1>?д@е@`CaCБCOGPGсKтK…N†NљSњS`XaXЬ\Э\Ю\у_ф_ ` `Уa$b“bJeKeVeWeшeХfCg=hУhФhХhЦhЩh˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜ 0€€˜ 0€€˜ 0€€˜ 0€€˜ 0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€˜0€€Чlk2њWЦlЧllnopqЧlmџџMatthew S. JaffeBC:\WINNT\Profiles\jaffem.000\Desktop\null_differential_testing.docўџџџџџџџџџџџџџџџџK?H џџџџџџџџџ*„h„˜ўЦh^„h`„˜ў.ўџџџфnаK?Hџџџџ№nа @hOJQJ^Jo(З№џџџџџџџџџ@€—а)ЧhP@џџUnknownџџџџџџџџџџџџG‡z €џTimes New Roman5€Symbol3& ‡z €џArial"ˆ№аhЯ*J†Я*J†‰м%f(eV,И!№ЅРxxƒj­2ƒ№пџџWPossibilities for Covert Write Down Detection via Null Differential, Marked Money Tests Matt JaffeMatthew S. Jaffeўџр…ŸђљOhЋ‘+'Гй0р˜   ,8L ht  œ Ј ДРШаифXPossibilities for Covert Write Down Detection via Null Differential, Marked Money Testsoss Matt Jaffeeattatt Normal.doteMatthew S. Jaffe Co2ttMicrosoft Word 9.0o@FУ#@о:2е‰Н@*„,ј.Р@*„,ј.Р(eVўџеЭеœ.“—+,љЎ0D hp€ˆ˜  ЈАИ Р $фERAUlИ,jэ XPossibilities for Covert Write Down Detection via Null Differential, Marked Money Tests Title  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrўџџџtuvwxyzўџџџ|}~€‚ўџџџ„…†‡ˆ‰Šўџџџ§џџџ§џџџŽўџџџўџџџўџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџRoot Entryџџџџџџџџ РF"о9ј.Р€1TableџџџџџџџџџџџџsWordDocumentџџџџџџџџ%фSummaryInformation(џџџџ{DocumentSummaryInformation8џџџџџџџџџџџџƒCompObjџџџџjObjectPoolџџџџџџџџџџџџ"о9ј.Р"о9ј.Рџџџџџџџџџџџџўџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџўџ џџџџ РFMicrosoft Word Document MSWordDocWord.Document.8є9Вq