Re: [cti-cybox] File/Artifact Encryption & Archive Properties

["Kirillov, Ivan A." <ikirillov@mitre.org>]

Two more items of note:

1. Earlier this week, Sean pointed me to the UCO structure for encrypted streams [1] – see example JSON here [2]. The main difference between our implementation and theirs is that our encryption algorithm vocabulary includes algorithm (method) and mode, whereas their structure breaks these up into separate properties. In addition, they have a property for capturing the initialization vector (IV) used.
2. We discussed the current issues and UCO’s approach during today’s additional working call. The consensus seems to be that our current vocabulary that captures encryption algorithm + mode is reasonable, since this is simpler than splitting the two out into separate properties, and this is also how this data is represented in other contexts. However, there seemed to be support for adding IV as a separate property, since this is a useful facet to capture. Also, we discussed that another use case is capturing how threat actors misuse/poorly implement encryption, particularly for attribution, so it would be nice to have some examples of this.

Anyhow, based on some of these recent discussions, I’m wondering if we can implement encryption as a dictionary with an associated standard vocabulary. That way, we can re-use this structure wherever we need to characterize encryption of a STIX Cyber Observable Object. As a strawman, it could look something like:

{
  "algorithm":"AES128-CBC",
  "init_vector_hex":"1122FFAA",
  "decryption_key":"foobar"
}

[1] https://ucoproject.github.io/uco/documentation/uco-v0.1.0-natural-language-glossary.html#EncryptedStream
[2] https://github.com/casework/case/blob/master/examples/file.json#L155-L159 

Regards,
Ivan

On 10/4/17, 11:51 AM, "Trey Darley" <trey@newcontext.com> wrote:

    On 04.10.2017 15:40:03, Kirillov, Ivan A. wrote:
    > > An encrypted zip file is different than just encrypting (and
    > > compressing) the file contents. Doing this would lose the
    > > mime_type of the file being compressed in the archive (if this is
    > > important).
    > 
    > That’s true, but since we’re discussing the Artifact Object in this
    > case, I don’t think we care about the contents as much as the
    > container (the actual “artifact”). If you need to characterize the
    > contents of an archive, you can still using the existing File Object
    > w/ archive-file-extension for this purpose.
    > 
    
    Exactly.
    
    > 
    > Also, I’m in agreement with Sean and others that it probably makes
    > the most sense to just add a new entry of “unspecified” to the
    > encryption-algo-ov, since this would cover all of our associated use
    > cases.
    > 
    
    I just added that to the encryption-algo-ov in STIX 2.1, Part 3.
    
    -- 
    Cheers,
    Trey
    ++--------------------------------------------------------------------------++
    Director of Standards Development, New Context
    gpg fingerprint: 3918 9D7E 50F5 088F 823F  018A 831A 270A 6C4F C338
    ++--------------------------------------------------------------------------++
    --
    "No matter how hard you try, you can't make a baby in much less than 9
    months. Trying to speed this up *might* make it slower, but it won't
    make it happen any quicker." --RFC 1925