Onderwerp: /dev/random is probably not

Most implementations of /dev/random (or so-called "entropy gathering daemons")
rely on disk I/O timings as a primary source of randomness. This is based on
a CRYPTO '94 paper[1] that analyzed randomness from air turbulence inside the
drive case.

I was recently introduced to Don Davis and, being the sort of person who
rethinks everything, I began to question the correctness of this methodology.
While I have found no fault with the original analysis (and have not actually
considered it much), I have found three major problems with the way it is
implemented in current systems. I have not written exploits for these
problems, but I believe it is readily apparent that such exploits could be
written.

a) Most modern IDE drives, at least, ship with write-behind caching enabled.
This means that a typical write returns a successful status after the data is
written into the drive's buffer, before the drive even begins the process of
writing the data to the medium. Therefore, if we do not overflow the buffer
and get stuck waiting for previous data to be flushed, the timing will not
include any air turbulence whatsoever, and should have nearly constant time.

b) At least one implementation uses *all* "disk" type devices -- including
flash devices, which we expect to have nearly constant time -- for timing.
This is obviously a bogus source of entropy.

c) Even if we turned off write-behind caching, and so our timings did include
air turbulence, consider how a typical application is written. It waits for,
say, a read() to complete and then immediately does something else. By
timing how long this higher-level operation (read(), or possibly even a
remote request via HTTP, SMTP, etc.) takes, we can apply an adjustment factor
and determine with a reasonable probability how long the actual disk I/O
took.

Using any of these strategies, it is possible for us to know the input data to
the RNG -- either by measurement or by stuffing -- and, therefore, quite
possibly determine the future output of the RNG.


Have a nice holiday weekend.


[1] D. Davis, R. Ihaka, P.R. Fenstermacher, "Cryptographic Randomness from Air
Turbulence in Disk Drives", in Advances in Cryptology -- CRYPTO '94
Conference Proceedings, edited by Yvo G. Desmedt, pp.114--120. Lecture Notes
in Computer Science #839. Heidelberg: Springer-Verlag, 1994.

Charles M. Hannum wrote:
> Most implementations of /dev/random (or so-called "entropy gathering daemons")
> rely on disk I/O timings as a primary source of randomness. This is based on
> a CRYPTO '94 paper[1] that analyzed randomness from air turbulence inside the
> drive case.

At least on Linux, the entropy pool is not only filled with data
from I/O timings, but also from networking I/O, user input events,
etc etc.[1]

Which specific implementations do you mean with "most implementations"?

Tom

[1] man 4 random

>
> I was recently introduced to Don Davis and, being the sort of person who
> rethinks everything, I began to question the correctness of this methodology.
> While I have found no fault with the original analysis (and have not actually
> considered it much), I have found three major problems with the way it is
> implemented in current systems. I have not written exploits for these
> problems, but I believe it is readily apparent that such exploits could be
> written.
>
> a) Most modern IDE drives, at least, ship with write-behind caching enabled.
> This means that a typical write returns a successful status after the data is
> written into the drive's buffer, before the drive even begins the process of
> writing the data to the medium. Therefore, if we do not overflow the buffer
> and get stuck waiting for previous data to be flushed, the timing will not
> include any air turbulence whatsoever, and should have nearly constant time.
>
> b) At least one implementation uses *all* "disk" type devices -- including
> flash devices, which we expect to have nearly constant time -- for timing.
> This is obviously a bogus source of entropy.
>
> c) Even if we turned off write-behind caching, and so our timings did include
> air turbulence, consider how a typical application is written. It waits for,
> say, a read() to complete and then immediately does something else. By
> timing how long this higher-level operation (read(), or possibly even a
> remote request via HTTP, SMTP, etc.) takes, we can apply an adjustment factor
> and determine with a reasonable probability how long the actual disk I/O
> took.
>
> Using any of these strategies, it is possible for us to know the input data to
> the RNG -- either by measurement or by stuffing -- and, therefore, quite
> possibly determine the future output of the RNG.
>
>
> Have a nice holiday weekend.
>
>
> [1] D. Davis, R. Ihaka, P.R. Fenstermacher, "Cryptographic Randomness from Air
> Turbulence in Disk Drives", in Advances in Cryptology -- CRYPTO '94
> Conference Proceedings, edited by Yvo G. Desmedt, pp.114--120. Lecture Notes
> in Computer Science #839. Heidelberg: Springer-Verlag, 1994.
>

Charles M. Hannum wrote:
> Most implementations of /dev/random (or so-called "entropy gathering daemons")
> rely on disk I/O timings as a primary source of randomness. This is based on
> a CRYPTO '94 paper[1] that analyzed randomness from air turbulence inside the
> drive case.
>

I would agree with the later analysis posted, but
what OSs use disk I/O timing only for /dev/{u,}random device
today?

- Linux? (I don't think so, If we have network and other I/O device
such as keyboard, I thought that would be used, too.
but I want confirmation from people in the know.)

- Solaris (I don't think so with the latest Solaris (7,8,9,10).
I read somewhere (probably here on bugtraq) that
it uses ever changing OS internal data structure and memory
pool as the partial source of entropy.
But again, I want confirmation from
someone who has seen, say, OpenSolaris source code.)

This leaves

OpenBSD, FreeBSD, NetBSD and the like, and of course
Windows family OSs.

People in the know may want to add comment about the
latter OSs.

My tenet is that two OSs that I use often, linux and solaris,
are free from the worry mentioned.
(When I think about it, I am not sure what Windows does
for random number generation.)

Looong time ago, SSH used to contain a so called
entropy gathering daemons that would run various simple
commands and use the output from these programs to
obtain quasi-random numbers by running the output
after hashing. But even then, they used
output not solely depending on the disk I/O randomness.
(system load, and bunch of other stuff. Granted, they
remain relatively constant on a non-busy system, but
they fluctuate enough for practical purposes.)
On a pre-solaris 7, I used this as "poor man's /dev/random".

One of these days, on desktop PCs,
we could add the reading of diode used for measuring
CPU temperature to the mix of
entropy source. (Of course, we need a good source of
`entropy' to begin with, and adding another source such
as diode is a good thing IMHO.)
And maybe the fan rotation/speed, too. I found that
they change constantly on my PC!

Some of these CPU-bound devices may have
implications when we have a dual core CPU.
Reading of such device by one thread may be
highly predictable by another thread running on the
CPU chip.


--
int main(void){int j=2003;/*(c)2003 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i ="g>qtCIuqivb,gCwe\np@.ietCIuqi\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */

Chiaki wrote:
> Charles M. Hannum wrote:
>
>> Most implementations of /dev/random (or so-called "entropy gathering
>> daemons") rely on disk I/O timings as a primary source of randomness.
>> This is based on a CRYPTO '94 paper[1] that analyzed randomness from
>> air turbulence inside the drive case.
>>
>
> I would agree with the later analysis posted, but
> what OSs use disk I/O timing only for /dev/{u,}random device
> today?
>
> - Linux? (I don't think so, If we have network and other I/O device
> such as keyboard, I thought that would be used, too.
> but I want confirmation from people in the know.)
>

From linux-2.4.31/drivers/char/random.c (the comments on top of
linux-2.6.12.2/drivers/char/random.c are identical);
* Sources of randomness from the environment include inter-keyboard
* timings, inter-interrupt timings from some interrupts, and other
* events which are both (a) non-deterministic and (b) hard for an
* outside observer to measure. Randomness from these sources are
* added to an "entropy pool", which is mixed using a CRC-like function.
* This is not cryptographically strong, but it is adequate assuming
* the randomness is not chosen maliciously, and it is fast enough that
* the overhead of doing it on every interrupt is very reasonable.
* As random bytes are mixed into the entropy pool, the routines keep
* an *estimate* of how many bits of randomness have been stored into
* the random number generator's internal state.
*
* When random bytes are desired, they are obtained by taking the SHA
* hash of the contents of the "entropy pool". The SHA hash avoids
* exposing the internal state of the entropy pool. It is believed to
* be computationally infeasible to derive any useful information
* about the input of SHA from its output. Even if it is possible to
* analyze SHA in some clever way, as long as the amount of data
* returned from the generator is less than the inherent entropy in
* the pool, the output data is totally unpredictable. For this
* reason, the routine decreases its internal estimate of how many
* bits of "true randomness" are contained in the entropy pool as it
* outputs random numbers.
*
* If this estimate goes to zero, the routine can still generate
* random numbers; however, an attacker may (at least in theory) be
* able to infer the future output of the generator from prior
* outputs. This requires successful cryptanalysis of SHA, which is
* not believed to be feasible, but there is a remote possibility.
* Nonetheless, these numbers should be useful for the vast majority
* of purposes.

The algorithm hasn't changed since 1999, when people started getting
interested in connection hijacking and tcp sequence number prediction
(anybody remember juggernaut?).

> - Solaris (I don't think so with the latest Solaris (7,8,9,10).
> I read somewhere (probably here on bugtraq) that
> it uses ever changing OS internal data structure and memory
> pool as the partial source of entropy.
> But again, I want confirmation from
> someone who has seen, say, OpenSolaris source code.)
>
> This leaves
>
> OpenBSD, FreeBSD, NetBSD and the like, and of course

Judging by nmap evaluation of the ip-stack, OpenBSD and FreeBSD have
very strong PRNG's as well. I haven't got access to a NetBSD system to
test with.

> Windows family OSs.
>

Redmond seems to have botched the implementation again, even though they
imported the BSD stack for NT5. Judging by nmap evaluation of ones
chances to success-fully predict the tcp-sequence numbers, it's possible
to degrade the internal state of the windows IP-stack by rhythmically
(but not necessarily rapidly) attempting to connect to a closed or open
port on the host, or one protected by the built-in windows firewall.
Third party firewalls doesn't seem to have this problem.

Note that I've only tested this on a single system, so it might be a
fluke or the result of wishful thinking or miscalculation on nmap's part.

I imagine this fails if someone watches a movie and/or is providing some
input from userland at the same time, although I haven't tested it.

/exon

*BSD uses Yarrow I think. Should also be safe from the concerns
mentioned.

http://www.schneier.com/yarrow.html


On Jul 2, 2005, at 9:08 AM, Thomas Wana wrote:


> OpenBSD, FreeBSD, NetBSD and the like, and of course
> Windows family OSs.
>

> - Linux? (I don't think so, If we have network and other I/O device
> such as keyboard, I thought that would be used, too.
> but I want confirmation from people in the know.)

It's been a while since I looked at the /dev/random design on Linux (probably
the early 2.4 days), however one thing that was quite clear was that they did
not use any network I/O as entropy sources because an attacker, particularly
one that already had control of other machines on the same LAN segment, could
have a high degree of control over that source. I would be most interested if
that has changed since the last time I looked at it.

> OpenBSD, FreeBSD, NetBSD and the like, and of course

Checking the /dev/random manpage on Darwin, it indicates that entropy is
input from the system "Security Server", which uses "kernel jitter".
Unfortunately, a quick check did not reveal exactly what the source of this
kernel jitter is. Never-the-less, the manpage does indicate that this
/dev/random design is from FreeBSD and likely shared with other BSDs.

> Windows family OSs.

All I can observe here is that F-secure SSH still (at least the most recent
version I've used) collects its own entropy when running on Win2K, which
indicates to me that either they want to operate the same on all Windows
versions (as memory serves, Win95/98 does not have a RNG), or that Win2k does
not have a suitable RNG.

> One of these days, on desktop PCs,
> we could add the reading of diode used for measuring
> CPU temperature to the mix of
> entropy source. (Of course, we need a good source of
> `entropy' to begin with, and adding another source such
> as diode is a good thing IMHO.)
> And maybe the fan rotation/speed, too. I found that
> they change constantly on my PC!

You would only want to use one or the other, since the fan rotation is a
function of the CPU temperature measurement -- if you used both you would
essentially be entering the same measurement into the RNG twice, which isn't
very random.

> Some of these CPU-bound devices may have
> implications when we have a dual core CPU.
> Reading of such device by one thread may be
> highly predictable by another thread running on the
> CPU chip.

Indeed -- certainly the recent advisory regarding information leakage through
the cache between threads on multi-core CPUs (CVN: CAN-2005-0109) indicates
that we're starting to find problems of this nature already.

Cheers,
Terry

#include <stddisclaim.h>

In some mail from exon, sie said:
> * If this estimate goes to zero, the routine can still generate
> * random numbers; however, an attacker may (at least in theory) be
> * able to infer the future output of the generator from prior
> * outputs. This requires successful cryptanalysis of SHA, which is
> * not believed to be feasible, but there is a remote possibility.
> * Nonetheless, these numbers should be useful for the vast majority
> * of purposes.

> Judging by nmap evaluation of the ip-stack, OpenBSD and FreeBSD have
> very strong PRNG's as well. I haven't got access to a NetBSD system to
> test with.

nmap is not a good measure of this problem.

Linux cited using keyboard interrupts. How many of those happen on
a web server in a rack, in an air conditioned computer room somewhere ?
How many happen when you open up your web browser and select your
internet banking web site from your bookmarks?

The original email pointed out that disk seek times may not be quite
as random as previously thought, especially with compact flash and
similar mediums.

In the case of polled I/O (for 1Gb+ NICs), is there any entropy
gained from network IRQ serving?

What the original article was getting at is that perhaps not all of
the information you think of as random information going into your
PRNG is actually random. If that happens then even though the
output of the PRNG "looks random", it may be predictable.

Darren

Hi List,

I think that the question here is different.

Why anyone is using the old entropy based RNG at all on modern commodity
hardware?

It is good if you know that your hardware operates in a manner which
provides good entropy and functions according to the RNG design. If the
platform does not do this, you might as well stay with the hardware
implementation present in most off the shelf hardware.

Via (from Nehemia core and upwards) - on CPU crypto quality RNG.

Intel - All chipsets from 82x onwards have a hardware RNG. It is thermal
noise based which is still likely to be better then deterministic IRQ
feeds from network and modern disks.

AMD - All chipsets in the 76x series have hardware RNG.

Others - well... Not all silicon is created equal I am afraid.

A.


Zow Terry Brugger wrote:

>>- Linux? (I don't think so, If we have network and other I/O device
>> such as keyboard, I thought that would be used, too.
>> but I want confirmation from people in the know.)
>>
>>
>
>It's been a while since I looked at the /dev/random design on Linux (probably
>the early 2.4 days), however one thing that was quite clear was that they did
>not use any network I/O as entropy sources because an attacker, particularly
>one that already had control of other machines on the same LAN segment, could
>have a high degree of control over that source. I would be most interested if
>that has changed since the last time I looked at it.
>
>
>
>> OpenBSD, FreeBSD, NetBSD and the like, and of course
>>
>>
>
>Checking the /dev/random manpage on Darwin, it indicates that entropy is
>input from the system "Security Server", which uses "kernel jitter".
>Unfortunately, a quick check did not reveal exactly what the source of this
>kernel jitter is. Never-the-less, the manpage does indicate that this
>/dev/random design is from FreeBSD and likely shared with other BSDs.
>
>
>
>> Windows family OSs.
>>
>>
>
>All I can observe here is that F-secure SSH still (at least the most recent
>version I've used) collects its own entropy when running on Win2K, which
>indicates to me that either they want to operate the same on all Windows
>versions (as memory serves, Win95/98 does not have a RNG), or that Win2k does
>not have a suitable RNG.
>
>
>
>>One of these days, on desktop PCs,
>>we could add the reading of diode used for measuring
>>CPU temperature to the mix of
>>entropy source. (Of course, we need a good source of
>>`entropy' to begin with, and adding another source such
>>as diode is a good thing IMHO.)
>>And maybe the fan rotation/speed, too. I found that
>>they change constantly on my PC!
>>
>>
>
>You would only want to use one or the other, since the fan rotation is a
>function of the CPU temperature measurement -- if you used both you would
>essentially be entering the same measurement into the RNG twice, which isn't
>very random.
>
>
>
>>Some of these CPU-bound devices may have
>>implications when we have a dual core CPU.
>>Reading of such device by one thread may be
>>highly predictable by another thread running on the
>>CPU chip.
>>
>>
>
>Indeed -- certainly the recent advisory regarding information leakage through
>the cache between threads on multi-core CPUs (CVN: CAN-2005-0109) indicates
>that we're starting to find problems of this nature already.
>
>Cheers,
>Terry
>
>#include <stddisclaim.h>
>
>
>
>
>


--
La Châtelier's Law:

If some stress is brought to bear on a system in equilibrium,
the equilibrium is displaced in the direction which tends to undo the
effect of the stress.

> Charles M. Hannum wrote:
> > Most implementations of /dev/random (or so-called "entropy gathering
daemons")
> > rely on disk I/O timings as a primary source of randomness. This is
based on
> > a CRYPTO '94 paper[1] that analyzed randomness from air turbulence
inside the
> > drive case.

At the last place at which I worked, a few years ago, a "random
number" was generated, and used in a FIPS 140-1 compliant
encryption device, by capturing 128 ethernet frames in sequence
from the local in-house network, gathering the LSB from the
arrival time of each frame, and using those values to generate
an encryption key. This was part of the "activation sequence"
which had to be done, once, on each such device.

Any studies out there on the randomness of such a number?
At first glance a non-deterministic network would seem to be
able to generate a useful number for the key.

- Bob Foxworth, GSEC, CISSP

> It's been a while since I looked at the /dev/random design on
> Linux (probably
> the early 2.4 days), however one thing that was quite clear was
> that they did
> not use any network I/O as entropy sources because an attacker,
> particularly
> one that already had control of other machines on the same LAN
> segment, could
> have a high degree of control over that source. I would be most
> interested if
> that has changed since the last time I looked at it.

If you're talking about a modern x86 system, you don't need to worry. Even
an attacker who had full view and control over the local LAN could not
predict the timing of network packets as seen by the CPU. There's entropy in
the offset between the network card's oscillator and the frequency
multiplier that produces the CPU core clock. The TSC at the time the packet
is noticed by the CPU still contains unpredictable entropy.

For every unforseen thing that makes the entropy not as good as we expect,
there's an unforseen thing that makes the entropy better than expected.
Realistically, there is nothing to worry about. (However, from a theoretical
standpoint, there's plenty of room for improvements and more provable
guarantees rather than "there's no known (or forseeable) way to break it".)

DS

"Zow" Terry Brugger wrote:

> It's been a while since I looked at the /dev/random design on Linux
> (probably the early 2.4 days), however one thing that was quite
> clear was that they did not use any network I/O as entropy sources
> because an attacker, particularly one that already had control of
> other machines on the same LAN segment, could have a high degree of
> control over that source.

They don't need to have any control; simply being able to observe
network traffic means that it is no longer random (in the sense of
"unpredictable", which is what counts from a security perspective).

--
Glynn Clements <glynn@gclements.plus.com>

On Sun, Jul 03, 2005 at 12:39:30PM -0700, Zow Terry Brugger wrote:

> It's been a while since I looked at the /dev/random design on Linux (probably
> the early 2.4 days), however one thing that was quite clear was that they did
> not use any network I/O as entropy sources because an attacker, particularly
> one that already had control of other machines on the same LAN segment, could
> have a high degree of control over that source. I would be most interested if
> that has changed since the last time I looked at it.

ISTR that grsecurity has toggles that enable gathering entropy from network
traffic. Assuming the PRNG is any good, it shouldn't matter if an attacker can
manipulate such timings, because (by definition) a good PRNG will still behave
correctly even if an attacker does feed it lots of deliberately bad data (as
long as the PRNG also has been fed with a sufficient amount of unguessable
'good' input as well, of course).

[...]
> > Windows family OSs.
>
> All I can observe here is that F-secure SSH still (at least the most recent
> version I've used) collects its own entropy when running on Win2K, which
> indicates to me that either they want to operate the same on all Windows
> versions (as memory serves, Win95/98 does not have a RNG), or that Win2k does
> not have a suitable RNG.

Only Win95 pre OSR2 is missing CryptoAPI (and specifically CryptGenRandom).
However, it's my understanding that early versions of CryptGenRandom were not
that great.

-Jack

remove
>>> Alexey Toptygin <alexeyt@freeshell.org> 7/6/2005 7:37:00 AM >>>
On Tue, 5 Jul 2005, Jack Lloyd wrote:

> Assuming the PRNG is any good, it shouldn't matter if an attacker can
> manipulate such timings, because (by definition) a good PRNG will still

> behave correctly even if an attacker does feed it lots of deliberately
> bad data (as long as the PRNG also has been fed with a sufficient amount

> of unguessable 'good' input as well, of course).

In the case of Linux, this still causes the estimate of how much 'good'
entropy is in the pool to be inflated. Some applications may rely on the
fact that /dev/random is backed by 'real' entropy, whereas /dev/urandom
can be pure PRNG output.

IMO, all this discussion is well and good, but it would be much more
productive for someone to settle the question empirically.

Alexey

> > At the last place at which I worked, a few years ago, a "random
> > number" was generated, and used in a FIPS 140-1 compliant
> > encryption device, by capturing 128 ethernet frames in sequence
> > from the local in-house network, gathering the LSB from the
> > arrival time of each frame, and using those values to generate
> > an encryption key. This was part of the "activation sequence"
> > which had to be done, once, on each such device.
> >
> > Any studies out there on the randomness of such a number?
> > At first glance a non-deterministic network would seem to be
> > able to generate a useful number for the key.
>
> It doesn't look like a good source of entropy. At least it wouldn't
> withstand an active attack during this activation phase.
>
>
> > - Bob Foxworth, GSEC, CISSP

What "active attack" allows an attacker to predict the jitter between the
network card's quartz oscillator and the frequency multiplier that generates
the CPU clock? The low order bit of the TSC at the time a packet is received
is believed to be almost purely a function of this jitter, for typical x86
CPUs at normal temperatures.

DS

--Apple-Mail-29-656466223
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed

As for the issue of getting randomness on a freshly-booted system,
Mac OS X will collect entropy over time and dump some to disk to be
reloaded next time the system reboots.
From the random (4) manpage:

OPERATION
The random device implements the Yarrow pseudo random number
generator
algorithm and maintains its entropy pool. Addditional entropy
is fed to
the generator regularly by the SecurityServer daemon from
random jitter
measurements of the kernel. SecurityServer is also responsible
for peri-
odically saving some entropy to disk and reloading it during
startup to
provide entropy in early system operation.

You may feed additional entropy to the generator by writing it
to the
random device, though this is not required in a normal
operating environ-
ment.

Now this raises some interesting issues - such as where is the
entropy written to, and how much does this pool of entropy set the
state of the RNG after bootup - ie, if an attacker had control of
this file, could they influence the RNG in a deterministic fashion
after forcing a reboot?

Kai Howells

On 06/07/2005, at 3:48 PM, Thomas wrote:

>> Linux cited using keyboard interrupts. How many of those happen on
>> a web server in a rack, in an air conditioned computer room
>> somewhere ?
>> How many happen when you open up your web browser and select your
>> internet banking web site from your bookmarks?
>>
>
> To complete the list, Linux uses:
> - block-device access
> - interrupt occurence
> - keyboard
> - mouse
> - freedback from pool extraction
> - pool extraction timing (doesn't matter)
>
> Even w/o devices such as keyboard and mouse Linux starts
> producing "a bit" entropy on an old notebook w/ just one hdd after
> about 2200 events (the end-phase of a booting SuSE Linux 9.0 system)
>
> Fortunately the pool is initialized in two stages... not perfect but
> sufficient for most systems.
>
> Twisting and stirring the bits should scatter entropy evenly in the
> pool.
> Afterwards hashing the pool contents, feeding back the hash value,
> and "folding" the hash value should be enough to stop every useful
> attack.
>
> Nevertheless I think it's time to retire for Linux' /dev/random
> implementation
> and use new approaches like Ferguson's Fortuna.
>
>
>
>> What the original article was getting at is that perhaps not all of
>> the information you think of as random information going into your
>> PRNG is actually random. If that happens then even though the
>> output of the PRNG "looks random", it may be predictable.
>>
>
> Unfortunately yes. At least for Linux I am not sure how accurate
> the entropy estimation really is. At least during boot it is much too
> optimistic.
>
>
>
>> Darren
>>
>
> Thomas Biege
>
> --
> Tom <tom@electric-sheep.org>
> fingerprint = F055 43E5 1F3C 4F4F 9182 CD59 DBC6 111A 8516 8DBF
>
>


--Apple-Mail-29-656466223
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
name=smime.p7s
Content-Disposition: attachment;
filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCS qGSIb3DQEHAQAAoIIGJDCCAt0w
ggJGoAMCAQICAw4P0DANBgkqhkiG9w0BAQQFADBiMQswCQYDVQ QGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVG hhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0EwHhcNMDUwMjE3MDQwNDMxWhcNMDYwMj E3MDQwNDMxWjBKMR8wHQYDVQQD
ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQ kBFhhrYWkuaG93ZWxsc0BpY29y
cC5jb20uYXUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAo IBAQDsi1bWdTRVzcnJNZRrB3I5
9KXpQz1yjwuK54+6FzQvFIwNq2BN8AW0ZxbQ/3s3NpXsyBqXwcvlY0hOV5RoN9H1e+6T5fIvtZWx
QeG3LlNxhOSXyQ7zrcnqcjpX57DjIOBvhnuxvWtEPjMR8hoItW QVqVexmAkjQOTBUHdPvbAhH7jL
JEEe6C0+50RX3R8Y4H+/jorE3giLLIRz220Z58wluwURN+NNzSv3huRpdBh2Vz8ef+s/2LyGE1ap
SgEe16thqPFQAY7TNO1/K54eo3P4NhiWQq13Cda6WlKWWpUGH8/YDQHZMI6ocdSJeiV6lsaazs+z
Lc2V5EUfAyOC2RGDAgMBAAGjNTAzMCMGA1UdEQQcMBqBGGthaS 5ob3dlbGxzQGljb3JwLmNvbS5h
dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAMM427 TOGppc3A3fBHVP9x4DbWBY/inV
Z/CWJpjduuEBdhiZaXlONlbZqiFR+l4b8DlTSZVmLnyNVhUJPW/4NLZdYnrgxT0qwek//sHTghim
PUStG6hKwR2gltyOY05Xa4sHwinA30UoUX18Y+xiaIgsiTwuTx xPQrIIMSla/4emMIIDPzCCAqig
AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWk ExFTATBgNVBAgTDFdlc3Rlcm4g
Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaG F3dGUgQ29uc3VsdGluZzEoMCYG
A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbj EkMCIGA1UEAxMbVGhhd3RlIFBl
cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZX Jzb25hbC1mcmVlbWFpbEB0aGF3
dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OV owYjELMAkGA1UEBhMCWkExJTAj
BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLD AqBgNVBAMTI1RoYXd0ZSBQZXJz
b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQ EBAQUAA4GNADCBiQKBgQDEpjxV
c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF
Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8
YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag
NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbm FsRnJlZW1haWxDQS5jcmwwCwYD
VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcm l2YXRlTGFiZWwyLTEzODANBgkq
hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg
k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jow gT2Vfldr394fWxghOrvbq
NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC 4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOD9AwCQYFKw 4DAhoFAKCCAVMwGAYJKoZIhvcN
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNz A3MDA1MzA3WjAjBgkqhkiG9w0B
CQQxFgQU/tuyDC5gwaKwf9mYyS4XIAObM58weAYJKwYBBAGCNxAEMWswaTB iMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTH RkLjEsMCoGA1UEAxMjVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw4P0DB6Bg sqhkiG9w0BCRACCzFroGkwYjEL
MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW 5nIChQdHkpIEx0ZC4xLDAqBgNV
BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIE NBAgMOD9AwDQYJKoZIhvcNAQEB
BQAEggEArMj+RJZrlFiNiOXq12ONNvk99jC9jeZfb2+jbcghgF NXAJivuHFwpAUxJMDJ9WGiTj3+
8qs75qfEoAfQHPOUJWC1HElXCwbtCa2QwYnJwpB2AZ5G61YavF p1GEBp+kDvRXEHt0CBwiPdNhH4
9D/xJbLyXEoSfcEGLr6Q/88yFk4t4vIR62I6nIVBkFlB4RI9wMBvoRVsoGtfRJ5d+/vP+zgGiF1K
7sO0Y2Hu0OZpCBMV5Ra53WO0OIAWJUgDxhXNgqm18RWrDqi1mb Rz47+M1enrJyJfraBk07P+SP6j
itVvuQoXXdl+2HDvEYZ0K7m2o1i+gaow9/kdvLuxw0r00gAAAAAAAA==

--Apple-Mail-29-656466223--