Quote:

I'd consider it an access mechanism; it does obfuscate the image file content, but not in a cryptographically strong way.

This particular feature very nearly cut short my involvement with Binary; I don't recall the exact sequence of events, but sometime around the time I was brought over this feature had been newly developed. Let's just say there weren't any security experts there at the time (not that I would claim to be either, given that I knew Peter Gutmann), and I made the point rather forcefully by demonstrating its' weakness in the classic way.

Which is not a way to make friends... but it did stop the feature being described as "encryption", in public or at least within my earshot.

[ Raymond Chen has the "Social Skills of a Thermonuclear Device" thing going on. In my case, my lack of tact earned me the description in the early 90's of "a minefield of information". ]

Quote:

No, but then it really only exists in the corporate product at all - any version - only to read images taken with consumer versions; you'll note we don't support passworded images in the management console and I have made a point of keeping it that way. I'd really like to remove the option completely.

The sanctioned replacement for that feature is the Symantec Client Migration system, and in 2.0 it's possible to use that to create a passworded migration package that I am told uses AES-256.

Thank you, Nbree and NightOwl, for your posts.

Nbree, I would encourage Symantec to reconsider the removal of the -PWD functionality, and to also pursue the addition of an “-AES” switch in GSS 2.0 that would actually encrypt the contents of the image file.  As the trend for full disk encryption increases (e.g., see Rapidly Expanding Use of Encryption to Protect Sensitive Data), it becomes important to encrypt the image of an encrypted partition - otherwise, the security benefit provided by the full disk encryption is compromised.  Norton Ghost 10 and 12, of course, provide this capability, so why not GSS 2.0?  And (who knows?) advancing this cause might accelerate your career, too!

In the absence of the ability to encrypt the image file during its creation, can you recommend any DOS or BartPE compatible tools for encrypting/decrypting a Ghost 2003/GSS 2.0 image file after it has been produced?

Nbree, that’s a good point about implementing AES encryption for a personal user versus for a corporation.  While the motivation for my question was based upon the former, I can see that adding encryption in a centrally managed environment involves a high level of complexity -- which, frankly, I was neglecting to consider.

NightOwl wrote on Sep 11^th, 2007 at 8:33am:

Yeah. Basically, these switches read the SMBIOS data tables which are defined by the DTMF consortium, the specifications for which can be got from here.

Manufacturers degree of implementation varies wildly. For instance, Dells that implement SMBIOS have many of the table data read from flash memory that can be set by their utilities. This tends to result in strange consequences; for instance, some Dell manufacturing processes end up burning identical data to the flash memory, including identical machine serial numbers and the UUID which is "guaranteed" by the specification to be unique to the hardware may also be shared by all the machines from the same run.

Other manufacturers do other things that are legal but tricky; almost all manufacturers put the SMBIOS data tables in memory in the same BIOS areas in the E0000-FFFFF where the anchor table is. IBM xSeries machines don't, which is perfectly spec-legal but takes some extra finesse in deal with addressing the physical memory location inside a DPMI DOS extender compared to the technique other manufacturers use.

Most of the big-name vendors have system BIOSes that generate all the data, and do it accurately; some motherboard vendors have BIOSes with the anchor tables but virtually none of the data is populated.

Anyway, because some manufacturers do let this be reprogrammed it's not entirely suitable as a security measure. VMWare is another way of spoofing this since although the SMBIOS data provided inside the virtual machine isn't completely reprogrammable, the machine UUID is able to be set by simply hand-editing the VMX file.

The BIOS lock feature was really intended primarily for OEMs to use the OEM Kit to produce recovery images that were bound to their hardware, not as a security thing as such but because they needed to do this to meet Microsoft's requirements for them to be able to use the cheaper OEM builds of Windows.