Re: Where are greater risks?

From: Dan Jones (djonesat_private)
Date: Fri Jun 29 2001 - 12:54:57 PDT

  • Next message: Michael D. Barwise, BSc, IEng, MIIE: "Re: Where are greater risks?"

    Mike,
    
    Ok, you make a good point about the desirability of having a
    does-one-thing-transparently tool.  And it would probably work fine,
    especially if you could be sure you had a target disk with the right
    geometry.  
    
    I am less convinced however, that this is really key issue.  True, it is
    critical that a correct copy be made.  But this can be demonstrated
    using things like checksums.  yes, that may be more challenging to
    explain to a jury, but if a jury isn't going to accept that concept then
    we are all in a lot of trouble.  After all, there are many technologies
    (DNA sampling comes to mind) that are not transparently simple yet are
    accepted as evidence.  Also, once you make your disk copy, you will
    still need to analyze it.  That will almost certainly be done by
    software running on top of some OS, for which the same issues that you
    identified earlier will arise.  So while the tool that you describe
    would reduce the scope for questioning the evidence, it would not
    eliminate it.  
    
    "Michael D. Barwise, BSc, IEng, MIIE" wrote:
    
    > Hi Dan
    > 
    > Yes, my idea (and it's only a suggestion) is that the copying engine does
    > absolutely nothing except read sector X from disk A and write the data read
    > to sector X of disk B, using a tiny native machine code routine. For IDE
    > interfaces, this would be truly trivial. This reasoning is based on the
    > possibility of a legal challenge to the concept of "exact copy". It would
    > seem possible to cast doubt on the exactness of a disk copy if any "high
    > level" process is used to perform the copying or it is performed over a
    > complex OS, simply because a technically inexpert counsel or jury will be
    > required to take this exactness on trust. However, the simple mechanism
    > outlined would be explicable without ambiguity even to such an audience.
    > The reason I thought of this was the numerous references to "stream
    > copying". Of course, we are *not* really dealing with a stream here: we are
    > transferring consecutive finite data blocks (sectors). Hence the suggestion.
    >
    
    
    -----------------------------------------------------------------
    
    This list is provided by the SecurityFocus ARIS analyzer service.
    For more information on this free incident handling, management 
    and tracking system please see:
    
    http://aris.securityfocus.com
    



    This archive was generated by hypermail 2b30 : Sat Jun 30 2001 - 09:54:04 PDT