Page History

...

   →   backup_enc_key.php

   → →   ajax_at_saving_backup_key.php

...

The database files which contains the Current User settings are used for back up. These database files are encrypted using the secure key entered by the User, scripts executed are backup_enc_key.php and ajax_at_saving_backup_key.php.

A tar file is generated with these encrypted files together and stored in temporary folder /tmp/. The tar file from temporary folder is downloaded to the Local PC of User.

...

The files which are uploaded in WebUI are extracted to get the encrypted database files. These database files are decrypted using the valid secure key entered by user.The secure key entered by user should be the same secure key which was entered earlier during encryption. If it is invalid, the decryption does not happen and restore fails.

The database files are saved to temporary folder /var/tmp/. The files are retrieved and replaced with the existing database files in RPi image.

...

Other Considerations (DAR)

It is required for the device to be rebooted once the Restore feature is executed successfully. This is because the settings which are updated to the database files when the backup file is uploaded, has to be applied, to be reflected in the WebUIsaved in an encrypted format to maintain the security of data, after backup.

During code development, two approaches were considered while designing the Restore feature.encryption/decryption

•  1st Approach: During Backup, the database files need to be encrypted to avoid corruption of data. The password used for user login to WebUI was considered as the secure key for encrypting the database files. This password is saved in the database files by default (though in the form of hashed password). The password has to be encoded and saved in a file to use for decryption during restore, to avoid conflict when restore is done after changing password for logging in WebUI. This causes high risk of security.
• 2nd Approach: During Backup, the user is asked to enter the secure key, which is used to encrypt the files. After encryption, during restore the user has to enter the same secure key to decrypt. If the secure key is invalid, a error message will be returned. at this point, the decryption does not happen and restore fails. This secure key is not saved anywhere
• 1st approach: After successful Restore, the device automatically boots to apply new settings, using the reboot command executed immediately after printing the message "Need Reboot to Save restore configurations"  in the upload_user_settings2.php file.
•  2nd approach: After successful Restore, the device automatically boots to apply new settings, using the "setStr("Device.X_CISCO_COM_DeviceControl.RebootDevice","Device",true);"  command executed immediately after printing the message "Need Reboot to Save restore configurations"  in the upload_user_settings2.php file.

The latter approach has been implemented as it was found to be more preferable and acceptable as compared to the former. This is because the former approach led to direct reboot of device without allowing the success message to be printed on Web screencauses risk of security as the password is accessible by user using database file or encoded file.

Architecture

...