File Expiration



  • <FONT face=Arial>This question concerns a large (enterprisey?) Java application.</FONT>

    <FONT face=Arial>The app uses a certain config file, which is supposed to be updated daily from a server.  However, due to network connectivity, etc it can't be guaranteed that the file will in fact be updated.</FONT>

    <FONT face=Arial>The goal is that this file can be identifed by the application as invalid if</FONT>

    <FONT face=Arial>1) it is not the most recent update, or</FONT>

    <FONT face=Arial>2) is has been modified in any way.</FONT>

    <FONT face=Arial>In other words, if the file is replaced, all older versions are invalid.  But we cannot be sure when/if the file is replaced.</FONT>

    <FONT face=Arial>I don't think this is possible.  But, I figured I'd bounce it off the smart people here.</FONT>



  • If your app remembers the modification date of the file, it can check if it has been updated or not. To make sure it has not been modified, you could either rely on file permissions (relatively unsafe) or you let the server sign it with it's private key. (Which, of course, requires some kind of authentification framework in place)



  • <FONT face=Arial>Good, but if the file has not been updated (server was disconnected, etc.) how can the app know not to expect a new file (updated modification date)?  I have a feeling the security I'm supposed to implement isn't possible with the framework I'm constrained to.</FONT>



  • @Eric Shinn said:

    <font face="Arial">Good, but if the file has not been updated (server was disconnected, etc.) how can the app know not to expect a new file (updated modification date)?  I have a feeling the security I'm supposed to implement isn't possible with the framework I'm constrained to.</font>



    If the file modification date is the same value your app remembered, the file hasn't changed. You could also do a md5 sum on the file to see if it has changed (probably better...)
    To get the modification date (well, the unix-like timestamp in seconds since 1970-01-01 00:00:00), you can use File.lastModified()



  • If this app is on Unix/Linux/BSD or similiar, beware the touch command as it will modify the last modified date.  I'd go with AmmoQ's suggestion and go with a checksum to validate modification - you'll be far less likely to run into collisions.



  • <FONT face=Arial>The checksum idea is a good one, and it looks like the route I'll go.</FONT>

    <FONT face=Arial>I think I will include the modified date in the data that is checksummed, to avoid insecurities in the last modified date as maintained by the OS (the app runs on w2k, but there are ways to change this date on windows, such as Java's File.setLastModified(...)).</FONT>



  • It would help greatly if you explained which parts of the system you trust, and which ones are considered dangerous.
    I will assume that the systems have no network connectivity, because if they did, you could simply download the file from the server.


    Do you trust the local system? If so, this whole issue is moot. Calculate a checksum on the server, and stick it in the config file. Verify the checksum to make sure the file transferred completely and isn't corrupted, and you're done.

    I think in all other cases you've already lost the battle.

    Is the file publicly accessible, but the program and os are trusted? I don't think you can win this one. If others can write to the file, they can replace the file with anything they wish, including a correct timestamp and checksum. One solution could be to use puplic-key cryptography. Generate keys for the server and the client, and encrypt all messages on the server. That way, you can decrypt it with your private key and the servers public key, and avoid messages from anyone else.

    If you can't trust the OS, then it's pointless. The OS has access to any data that your program stores (i.e. any hashes, private keys, the executable program itself) and can modify it at will without any chance of you noticing.




  • @Nandurius said:

    One solution could be to use puplic-key cryptography. Generate keys for the server and the client, and encrypt all messages on the server. That way, you can decrypt it with your private key and the servers public key, and avoid messages from anyone else.


    Even then, you have to beware of replay attacks - the attacker could write a valid (signed) config file which is 14 days old to the share...



  • @ammoQ said:

    @Nandurius said:
    One solution could be to use puplic-key cryptography. Generate keys for the server and the client, and encrypt all messages on the server. That way, you can decrypt it with your private key and the servers public key, and avoid messages from anyone else.


    Even then, you have to beware of replay attacks - the attacker could write a valid (signed) config file which is 14 days old to the share...


    timestamp the config file within the encrypted section.  that way if someone does a replay attack you will see that the file is old. 



  • @Nandurius said:

    It would help greatly if you explained which parts of the system you trust, and which ones are considered dangerous.
    I will assume that the systems have no network connectivity, because if they did, you could simply download the file from the server.


    Do you trust the local system? If so, this whole issue is moot. Calculate a checksum on the server, and stick it in the config file. Verify the checksum to make sure the file transferred completely and isn't corrupted, and you're done.

    I think in all other cases you've already lost the battle.

    Is the file publicly accessible, but the program and os are trusted? I don't think you can win this one. If others can write to the file, they can replace the file with anything they wish, including a correct timestamp and checksum. One solution could be to use puplic-key cryptography. Generate keys for the server and the client, and encrypt all messages on the server. That way, you can decrypt it with your private key and the servers public key, and avoid messages from anyone else.

    If you can't trust the OS, then it's pointless. The OS has access to any data that your program stores (i.e. any hashes, private keys, the executable program itself) and can modify it at will without any chance of you noticing.


    <FONT face=Arial>I think the spec reads something like: "Trust nothing.  Everything must be completely secure, and completely availible.  Everywhere."</FONT>

    <FONT face=Arial>I just need it to feel secure enough that our info. security team will stamp it okay.  As you said:</FONT>

    Is the file publicly accessible, but the program and os are trusted? I don't think you can win this one.
    <FONT face=Arial>Thats pretty much the deal.</FONT>

    <FONT face=Arial>And, BTW, the codebase is owned by Oracle.  I know how well they are liked in these parts. ;)</FONT>


Log in to reply