Using NSValueTransformer for encryption

  • Hi,

    I need to include encryption in my Core Data application. Consider
    the following example: If I'd use the XML Store, I would encrypt
    only the values, not the whole XML file. For encryption/decryption
    I want to use a NSValueTransformer to perform the encryption/decryption
    if it's needed. It can take the encrypted value from the store, decrypt
    it and deliver the decrypted value to the UI (and vice versa). Do
    you think it will be possible to perform encryption/decryption this
    way? In the data model the values that will be encrypted would have been of type "binary" on order to keep the encrypted values, haven't they?

    I belive, that an advantage of this solution would be that there won't be any decrypted values in the memory footprint of the application as long as there are any values displayed. (I think you have to manually set the values of UI elements displaying the decrypted values after closing the window which contains these elements).

    Please, tell me what you think about this. Many thanks in advance.

    Michael
    --
    Psssst! Schon vom neuen GMX MultiMessenger gehört?
    Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger?did=10
  • on 1/10/08 1:32 AM, <M.Varlik...> purportedly said:

    > I need to include encryption in my Core Data application. Consider
    > the following example: If I'd use the XML Store, I would encrypt
    > only the values, not the whole XML file. For encryption/decryption
    > I want to use a NSValueTransformer to perform the encryption/decryption
    > if it's needed. It can take the encrypted value from the store, decrypt
    > it and deliver the decrypted value to the UI (and vice versa). Do
    > you think it will be possible to perform encryption/decryption this
    > way? In the data model the values that will be encrypted would have been of
    > type "binary" on order to keep the encrypted values, haven't they?

    The main drawback to this approach is that the transformer can't easily know
    whether a value is encrypted or not, which isn't an issue if you don't want
    the values editable.

    I would recommend encrypting/decrypting on load/save for the most
    robustness.

    > I belive, that an advantage of this solution would be that there won't be any
    > decrypted values in the memory footprint of the application as long as there
    > are any values displayed. (I think you have to manually set the values of UI
    > elements displaying the decrypted values after closing the window which
    > contains these elements).

    I am not sure what you are saying here--if the data exists in your
    application at any moment whatsoever in an unencrypted form, it is (at that
    moment, at least) exposed in the application's memory space, and therefore
    discoverable by inspecting the memory space. Even if the value isn't
    currently displayed, depending on other issues such as the state of the
    autorelease pool or other garbage collection, the value may still exist in
    memory space and be discoverable.

    Best,

    Keary Suska
    Esoteritech, Inc.
    "Demystifying technology for your home or business"
  • -------- Original-Nachricht --------
    > Datum: Thu, 10 Jan 2008 09:26:06 -0700
    > Von: Keary Suska <hierophant...>
    > An: "Cocoa-Dev (Apple)" <cocoa-dev...>
    > Betreff: Re: Using NSValueTransformer for encryption

    > on 1/10/08 1:32 AM, <M.Varlik...> purportedly said:
    >
    >> I need to include encryption in my Core Data application. Consider
    >> the following example: If I'd use the XML Store, I would encrypt
    >> only the values, not the whole XML file. For encryption/decryption
    >> I want to use a NSValueTransformer to perform the encryption/decryption
    >> if it's needed. It can take the encrypted value from the store, decrypt
    >> it and deliver the decrypted value to the UI (and vice versa). Do
    >> you think it will be possible to perform encryption/decryption this
    >> way? In the data model the values that will be encrypted would have been
    > of
    >> type "binary" on order to keep the encrypted values, haven't they?
    >
    > The main drawback to this approach is that the transformer can't easily
    > know
    > whether a value is encrypted or not, which isn't an issue if you don't
    > want
    > the values editable.
    >
    > I would recommend encrypting/decrypting on load/save for the most
    > robustness.
    >
    >> I belive, that an advantage of this solution would be that there won't
    > be any
    >> decrypted values in the memory footprint of the application as long as
    > there
    >> are any values displayed. (I think you have to manually set the values
    > of UI
    >> elements displaying the decrypted values after closing the window which
    >> contains these elements).
    >
    > I am not sure what you are saying here--if the data exists in your
    > application at any moment whatsoever in an unencrypted form, it is (at
    > that
    > moment, at least) exposed in the application's memory space, and therefore
    > discoverable by inspecting the memory space. Even if the value isn't
    > currently displayed, depending on other issues such as the state of the
    > autorelease pool or other garbage collection, the value may still exist in
    > memory space and be discoverable.

    Consider the following example: The user edits a text whose stringValue
    shall be encrypted. After endEditing the value is passed to the managed
    object which stores it. This is where the value transformer comes into play.
    It takes the value from the text field, encrypts it and passes the encrypted
    value to the managed object. After that, the string value of the text field
    has to be set to an empty string which sould remove the unencrypted value from
    memory. Decrypting a value from the managed object is just the other way around.

    I hope this makes my idea a bit mor clear.

    Best regards,
    Michael

    >
    > Best,
    >
    > Keary Suska
    > Esoteritech, Inc.
    > "Demystifying technology for your home or business"

    --
    Psssst! Schon vom neuen GMX MultiMessenger gehört?
    Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger?did=10
  • on 1/10/08 1:29 PM, <M.Varlik...> purportedly said:

    > Consider the following example: The user edits a text whose stringValue
    > shall be encrypted. After endEditing the value is passed to the managed
    > object which stores it. This is where the value transformer comes into play.
    > It takes the value from the text field, encrypts it and passes the encrypted
    > value to the managed object.

    The transformer will work, you'll just need to make sure the "encrypted"
    state of he text is guaranteed from the perspective of the transformer. If
    the value is only stored and maintained in the model in an encrypted form,
    and only edited by the UI, then so you probably won't have problems with
    using a transformer.

    > After that, the string value of the text field has to be set to an empty
    > string which sould remove the unencrypted value from memory.

    This will not guarantee, in any way, that the value will truly be removed
    from memory. Just so you know.

    Best,

    Keary Suska
    Esoteritech, Inc.
    "Demystifying technology for your home or business"
  • On Jan 10, 2008, at 12:29 PM, Michael Varlik wrote:

    > The user edits a text whose stringValue
    > shall be encrypted. After endEditing the value is passed to the
    > managed
    > object which stores it. This is where the value transformer comes
    > into play.
    > It takes the value from the text field, encrypts it and passes the
    > encrypted
    > value to the managed object.
    >
    If you're using Leopard, it may be easier to use transformable
    attributes...
    <http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/Articles
    /cdNSAttributes.html#//apple_ref/doc/uid/TP40001919-DontLinkElementID_58
    >

    mmalc
  • Hi Michael,

    > I belive, that an advantage of this solution would be that there
    > won't be any decrypted values in the memory footprint of the
    > application as long as there are any values displayed.

    Why is this an advantage?

    Additionally, even if the values weren't cleartext in memory at any
    given point, the encrypted values along with the decryption code and
    key would be.

    Jonathon Mah
    <me...>
  • -------- Original-Nachricht --------
    > Datum: Fri, 11 Jan 2008 11:38:11 +1030
    > Von: Jonathon Mah <me...>
    > An: Michael Varlik <M.Varlik...>
    > CC: <cocoa-dev...>
    > Betreff: Re: Using NSValueTransformer for encryption

    > Hi Michael,
    >
    >> I belive, that an advantage of this solution would be that there
    >> won't be any decrypted values in the memory footprint of the
    >> application as long as there are any values displayed.
    >
    >
    > Why is this an advantage?
    >
    > Additionally, even if the values weren't cleartext in memory at any
    > given point, the encrypted values along with the decryption code and
    > key would be.
    >
    Hi Jonathon,

    this would only be an advantage, if you remove the key as well after
    it's been used. There's still a small time frame where the key is stored in memory - but this is the same with the unencrypted values.

    Best regards,
    Michael

    >
    >
    > Jonathon Mah
    > <me...>

    --
    Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
    Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
  • -------- Original-Nachricht --------
    > Datum: Thu, 10 Jan 2008 14:27:03 -0700
    > Von: Keary Suska <hierophant...>
    > An: Michael Varlik <M.Varlik...>, "Cocoa-Dev (Apple)" <cocoa-dev...>
    > Betreff: Re: Using NSValueTransformer for encryption

    > on 1/10/08 1:29 PM, <M.Varlik...> purportedly said:
    >
    >> Consider the following example: The user edits a text whose stringValue
    >> shall be encrypted. After endEditing the value is passed to the managed
    >> object which stores it. This is where the value transformer comes into
    > play.
    >> It takes the value from the text field, encrypts it and passes the
    > encrypted
    >> value to the managed object.
    >
    > The transformer will work, you'll just need to make sure the "encrypted"
    > state of he text is guaranteed from the perspective of the transformer. If
    > the value is only stored and maintained in the model in an encrypted form,
    > and only edited by the UI, then so you probably won't have problems with
    > using a transformer.
    >
    >> After that, the string value of the text field has to be set to an empty
    >> string which sould remove the unencrypted value from memory.
    >
    > This will not guarantee, in any way, that the value will truly be removed
    >> from memory. Just so you know.
    >
    Hi Keary,

    what's the reason for that? Is there a new NSString object created when I
    modify a NSTextField's stringValue?

    Best regards,
    Michael

    > Best,
    >
    > Keary Suska
    > Esoteritech, Inc.
    > "Demystifying technology for your home or business"

    --
    Psssst! Schon vom neuen GMX MultiMessenger gehört?
    Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger?did=10
  • on 1/10/08 11:47 PM, <M.Varlik...> purportedly said:

    >> This will not guarantee, in any way, that the value will truly be removed
    >> from memory. Just so you know.
    >>
    > Hi Keary,
    >
    > what's the reason for that? Is there a new NSString object created when I
    > modify a NSTextField's stringValue?

    I am mostly talking about a couple of issues: 1) the lifecycle of
    autoreleased objects are difficult to predict; and 2) even when an object is
    released and memory is freed, the values can still exist in memory in an
    intact form. AFAIK, memory is not zeroed out when it is freed, so a sequence
    of bytes may still exist.

    Combining issues of bindings, editing, and display, strings can be retained,
    copied, and autoreleased. Other issues can also effect the life of an
    object, such as modal sessions, where the autorelease pool will not be
    cleared until the session ends.

    There are also other things that I am likely overlooking, but I would say
    that the bottom line is simply that setting the NSTextField string vale to
    an empty string will not necessarily make the decrypted value disappear.

    Here is a somewhat simple, although not definitive, test: decrypt the value,
    change the NSTextField, run the run loop (should purge the autorelease
    pool), then dump core. Scan core for a series of bytes matching decrypted
    value. If it's not there, then you could say that discovering the decrypted
    value is impractical enough that someone without free access to the computer
    that the application is on is not likely able to discover it. However,
    someone with physical access to the computer could get the data regardless
    of what you do. There is no way around this other than using external
    devices such as encryption cards or dongles that are not kept with the
    machine, and even then....

    Anyway, as long as you are employing secure programming best practices, that
    is the best you can do. You really can't guarantee anything, especially with
    Obj-C.

    Best,

    Keary Suska
    Esoteritech, Inc.
    "Demystifying technology for your home or business"
previous month january 2008 next month
MTWTFSS
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      
Go to today