Re: Re: Russ Housley: Fwd: problems with draft-ietf-tls-openpgp-keys-10.txt
Kyle Hamilton <aerowolf <at> gmail.com>
2006-07-01 11:36:38 GMT
On 7/1/06, Nikos Mavrogiannopoulos <nmav <at> gnutls.org> wrote:
>
> Maybe the wording wasn't clear. Would an update to the security
> considerations text like the one below be more clear to you?
>
> Security considerations about the use of the web of trust or
> the key verification procedure are outside the scope of this
> document and are considered issues to be handled by the
> application layer protocols.
Security considerations that have anything to do with identity key
verification and entity mapping (pre-shared keys, PKIX, web-of-trust),
and the corresponding authorization to use the application being
protected, are outside the scope of this document. These are
considered issues to be handled by the application layer protocols, or
at the very least by the TLS implementation in accordance with
key-interpretation protocols that are separately described.
The use of cryptographic keys, and the cryptographic keys so used, can
be exposed through a kernel or process memory dump or process
debugging feature of many operating systems. This means that any
entity who has access to kernel memory, process debugging, or perhaps
even process-listing facilities may be able to subvert the entity
identification procedures, and may be able to decrypt the data within
any TLS session identified and authenticated with that private key if
it is captured through such mechanisms. In addition, identity key
processing and storage may be compromised through insecure backup
procedures, insecure passing of identity key decryption information to
processes, non-reset (i.e., non-zeroed) contents of memory blocks
being allocated to other processes, privileged or physical access to
the machine that the TLS implementation is running on, and other ways.
These are issues which are implementation-specific, and only very
basic suggestions can be given.
For example, not all operating systems properly clear memory (or
paging files) which is paged out or upon release of memory by a
process back to the system. This suggests that identity key and
session information could be kept in memory or on disk indefinitely.
Because of this, applications and implementations should take care to
clear or completely randomize any memory which contains key
information when it is no longer needed, and to prevent paging of the
key information if at all possible. If session information is cached
(for example, to a database of some kind which can be used by other
processes), it may be cached in a place where the implementation
cannot exert complete control over the storage used. It is likely
best in these situations to encrypt session data with a locally-known
symmetric key [or perhaps a hybrid approach utilizing the public key
corresponding to the private key used for identity] before writing it
to the cache. This is particularly important with network-based
caching systems, as database implementations may not adequately
encrypt the data for transport and the network should be viewed as
"insecure" as practically possible.
As well, once sessions expire their data should be removed from the
cache as soon as possible, in a manner designed to overwrite that data
as destructively as possible. (For example, one could use an
autocommited UPDATE command in SQL, and only then issue an
autocommitted DELETE FROM command. This will not work with databases
that have recovery capabilities, though, and application
administrators are encouraged to look for means of forcing full
commission and data backup from such databases' log files to the main
database so that those log files may be removed as soon as practical.)
At any time, specific algorithms may be discovered to have flaws. (At
the time of this writing, the MD5 hash function is known to have
serious weaknesses which permit an attacker to create hash collisions
in a matter of seconds, and the same methods used to discover this
attack are being utilized against other hashing algorithms.)
Implementors and application administrators are encouraged to keep an
eye on the cryptographic state of the art, and regularly review the
security policies implemented within their software and on their
hosts.
Implementations with poor random number generation capabilities are
known to have much more vulnerability, as the random numbers generated
could have many fewer possible values than implementations with better
random number generators. It is generally recommended to use a
physical source of entropy (geiger-counted emissions, aerodynamic and
thermodynamic properties of devices which produce unpredictable
results, ambient room noise, and many others) when at all possible.
It is VITAL that implementations NEVER REUSE ANY GIVEN ENTROPY, to
make symmetric key-guessing and asymmetric private key calculation at
least as difficult as the number of bits held within the key.
Certain algorithms have "weak keys", and implementations of those
algorithms should check generated keys against them and reject them as
candidates for usage.
The RSA asymmetric encryption system is known to be vulnerable to
advances in factoring large numbers. In particular, the General
Number Field Seive is being advanced slowly but inexorably. It is
recommended that implementations move away from RSA for identity keys.
Certain jurisdictions require the use of a limited set of algorithms
(for example, the US Federal Government requires the use of AES for
symmetric key operations, and a specific PNRG for random number
generation). Implementations should allow the application
administrator to remove supported cipher suites or to add only a
specific list of known-good cipher suites for use, and to specify how
entropy is generated for the algorithms used.
...
Any thoughts on anything to add?
-Kyle H
RSS Feed