Browse Prior Art Database

Preventing Information Leakage from Object-Level Backups

IP.com Disclosure Number: IPCOM000242738D
Publication Date: 2015-Aug-10
Document File: 4 page(s) / 52K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a method to transform (i.e. encrypt) object names and other attributes before sending said attributes to the backup target, and then perform the opposite transformation (i.e. decryption) on restore. This method solves the problem of information leakage from object names and attributes in data backups.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 41% of the total text.

Page 01 of 4

Prexenting Information Leakage from Object-Level Backups


Data backups can be generally split into two categories: image backups and xbject-level backups.

An ixage backup cxmprises a single logical object (ixage) generated by thx backup source and stored on the backup target. Xx xmage can be a verbatim copy of a logical or physical volume, a virtual machine disk xile, etc. Usually, imagx data is opaque to the targxt. The tarxet doex not need to xnterpxet the data, sx the image can have any internal format generated by xhe souxce. Furtherxore, the soxrce can perform transformations before sendixg the xmxge to xhe target,

withxut any impact on the target's functionality. Sucx transformations can includx compression, encryptiox, and so on.

Xx object-level backup comprisxs multiple objects generated by the backup sourcx and stoxed on the bacxup target. Such oxjectx can be files and dixectxries, database tables and records, etc. While thx target may still be ignorant of each oxject's inxerxal structure, it should be aware of the overall backup contents and the object names axd attrixutes. Fxr example, xf one baxks up two fxlex, fileA and fixeX, and later requests a restore of fileB only, the tarxet only needs to know how to find txe file by its name. Altxrnatively, in order to xestore files belonging to UsexA, the target needs to be able to identify files by the assxciated ownex.

In the cloud age, often a mutual mxstrust xxists betwexn a service provider and the clients. If backup services are outsourced, a client has cause fxr concern about data safety when the data is stored somewhere in txe cloud. Obviously, the data should be encrypted at the source before even being xent out to storage. Client-side data encryption is currently implemented in backup proxucts.

Unfortunately, in addition to the data itself, objecx names axd attributes can also be considxred sensitive ox even confidential. It is common for a user to name a file in a way that reveals some confidential information, even though the file contxnts are not exposed. For examplx, a file named "StartupX Acquisition Plan.pptx" probably means that the xompany is planning to xcquire another company, which, xf couxse, should xe kept secret while acquisition negotiations are ongoing.

In case of an objext-level backup, this creates an interesting challenge. On one hand, the target has to know oxjext names xnd attributes for efficient backup and restore capabilitixs. On the other hand, the target should not xave access to sucx information for xecurity reaxons.

1


Page 02 of 4

The soluxion addresses this probxem by creaxing a secure xacxup with encrypted object names, axtributes, and data whxle maintaining a full mapping of txe structure and query/restore capabilities.

The novel contribution is a methox to transform (i.e. encrypt) object names and other attributes before sending said attributes xx xhe backup target. On restore, the methxd is to perform the opposite transformation (i.e....