[gnutls-devel] [PATCH 3/3] _asn1_ordering_set_of(): Fix memory leak in case of error.

[Peter Williams]

is no longer a secret that set of (sequence of) was used, even as far back as the v1 certs era, to do things that the spec “enabled” but did not specify. This is the usual example of an ISO spec in the security track having different meanings (as intended by those with classified knowledge). IN the profile, such features are used - e.g. MISSI profiles of X.509 and X.5.11.


One MIGHT know that a signed object is typically a signing action over a SETOF/SEQOF explicitely-tagged elements. But, one might ALSO know that such a typed value MIGHT be encoded on the wire with extra tagged elements not standarized by the spec. (X.509 v1 allowed this, and conforming implementations MUST not object). Thus on the wire, a sender OR RELAY can omit a mandatory tag from the concrete encoding of a given value, and ADD a custom tag (with an pairwise-encrypted copy of the missing standard tag, say). To verify the signature one has to process the custom tag to decrypt the value, that then completes the PDV and would allow the signature to verify.



One of those lovely examples in which the public line of the authentication framework was: that ISO had not enabled open systems encryption (allowing for certain national politics to claim success). But, at the same time, in double-speak, to do the exact opposite of what the public claims were. Its also an example of a once-classified that was all abou policy (and negotiation stances) vs some super-secret technology.






From: peter Msn
Sent: ‎Sunday‎, ‎April‎ ‎20‎, ‎2014 ‎10‎:‎25‎ ‎AM
To: gnutls-devel at lists.gnutls.org





off topic.




Remember, ASN.1 is abstract and begets several concrete encodings. In particular, BER was INTENDED to allow (security) processors doing relaying to reorder set elements on the wire (or drop tagged elements they just could not process). IN the associated doctrine for ASN.1 - heavily used in 1990s era military messaging system security concepts, one should not assume that the inbound wire has the originator’s instance of BER coding or all the originally-tagged data elements.  Recoding into the canonical form (of those elements actually received) is of course the classical DER requirement - used when performing a security services on the inbound PDU.




As I recall, canonical encoding set of requires forming a binary representation of the collection of child TLVs, and doing a binary compare to order the set.




If the code to do all this is within the security module (within the FIPS 140 crypto module boundary that is) one gets to time all this activity, since one can inject different orderings under these BER rules and induce difference amount of work - and associated energy/power usage.




Sneaky, no!

 

One might leak the raw signal in one module, and then, ahem, induce another - via garbage collection etc - to modulate that signal on a suitable bearer easily available to the party penetrating the commodity crypto module.






From: Kurt Roeckx
Sent: ‎Sunday‎, ‎April‎ ‎20‎, ‎2014 ‎7‎:‎59‎ ‎AM
To: gnutls-devel at lists.gnutls.org





On Sat, Apr 19, 2014 at 08:13:58PM +0200, Kurt Roeckx wrote:
> I need to look at this again, more examples cases of it in the
> same file different function.  And I might have misunderstood the
> intention of the function, so I'm looking at this again.

So I ended up submitting a reworked version of this patch and a
few others to libtasn1.


Kurt


_______________________________________________
Gnutls-devel mailing list
Gnutls-devel at lists.gnutls.org
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140421/e743d0ef/attachment-0001.html>
-------------- next part --------------
_______________________________________________
Gnutls-devel mailing list
Gnutls-devel at lists.gnutls.org
http://lists.gnupg.org/mailman/listinfo/gnutls-devel