With SEB 3.5.0/Win/x64 the BEK key keep changing

[rabser]

We would like to step up from x86/32bit SEB to x64/64bit application on Windows 11/22H2 but we experienced a strange behaviour: every time that we load (nb. never saving) the configuration into the SEB cftool, we get a different BEK.
As this does not happen with the 32bit application on the same system, we were wondering if this is the right behaviour or if there's anything we are missing ?
On the usage side, Moodle 4.x (either x=0,1,2,3), the effect is that the BEK challenge fails, but this is not so strange if I can't copy and paste "the" BEK for my workstation.

Any hints is welcome!

[dbuechel]

No, that should not be this way. When loading the same configuration, the configuration tool should also display the same (unique) Browser Exam Key (as well as Configuration Key). Which SEB version are you using? And would you mind posting the log file of the configuration tool? It can be found under %AppData%\SafeExamBrowser\SebConfig.log.

[rabser]

We found the SebConfig.log under %AppData%\Roaming\SafeExamBrowser (the user is the local Administrator account) and the interesting lines are the following:

11/10/2023 12:48:00 [Information]: Initializing browser exam key...

11/10/2023 12:48:00 [Warning]: The current configuration does not contain a salt value for the browser exam key!

11/10/2023 12:48:00 [Information]: Successfully calculated BEK using integrity module.

11/10/2023 12:48:00 [Information]: OnLoad EventArgs: C:\Program Files\SafeExamBrowser\Configuration\SEBConfigTool.exe

11/10/2023 12:48:02 [Information]: Initializing browser exam key...

11/10/2023 12:48:02 [Warning]: The current configuration does not contain a salt value for the browser exam key!

11/10/2023 12:48:03 [Information]: Successfully calculated BEK using integrity module.

11/10/2023 12:48:07 [Information]: Loading settings from file C:\ProgramData\SafeExamBrowser\SebClientSettings.seb

11/10/2023 12:48:10 [Information]: Initializing browser exam key...

11/10/2023 12:48:10 [Information]: Successfully calculated BEK using integrity module.

11/10/2023 12:51:14 [Information]: Initializing browser exam key...

11/10/2023 12:51:14 [Information]: Successfully calculated BEK using integrity module.

11/10/2023 12:51:18 [Information]: Loading settings from file C:\ProgramData\SafeExamBrowser\SebClientSettings.seb

11/10/2023 12:51:18 [Information]: Initializing browser exam key...

11/10/2023 12:51:19 [Information]: Successfully calculated BEK using integrity module.

11/10/2023 12:52:15 [Information]: Initializing browser exam key...

11/10/2023 12:52:15 [Information]: Successfully calculated BEK using integrity module.

11/10/2023 12:52:18 [Information]: Loading settings from file C:\ProgramData\SafeExamBrowser\SebClientSettings.seb

11/10/2023 12:52:18 [Information]: Initializing browser exam key...

11/10/2023 12:52:18 [Information]: Successfully calculated BEK using integrity module.

11/10/2023 12:52:55 [Information]: Initializing browser exam key...

11/10/2023 12:52:55 [Information]: Successfully calculated BEK using integrity module.

11/10/2023 12:52:59 [Information]: Loading settings from file C:\ProgramData\SafeExamBrowser\SebClientSettings.seb

11/10/2023 12:52:59 [Information]: Initializing browser exam key...

11/10/2023 12:52:59 [Information]: Successfully calculated BEK using integrity module.

where each "block" it's a new load of the same .seb configuration file without saving.
Feel free to ask anything you can think useful to debug this wrong behaviour.
The SEB version is 3.5.0 Win/64bit, downloaded and installed this morning (in Italy...).

[dbuechel]

I can see one issue which would explain the behavior:

11/10/2023 12:48:00 [Warning]: The current configuration does not contain a salt value for the browser exam key!

Without a valid salt value as part of a configuration, the BEK will always be random! Where is the configuration coming from that you're trying to open? Is it a configuration you created manually, or is it e.g. downloaded from an LMS?

[rabser]

Thanks for the hint: the configuration was created by us manually, no download from moodle (i.e.).
But, but... The Warning about the salt is printed because we store the seb configuration file in the machine profile, so at first run of the conftool, the config file it's not found at all, and that warning comes out.
To double check we created a new config by scratch into the user profile, the warning disappeared, but enabling the BEK/CK feature, again, reopening the configuration, BEK keeps changing every time.

[rabser]

After some hours of investigation, we suspect that the root cause it's the latest MS Visual C++ Redistributable 2015-2022 14.36.32532 that is the actual package release.
We did a complete erase of these libraries (manually erasing from %windir%\System32 ) and installed an older one downloaded from MyVisualStudio which was an MS Visual C++ Redistributable 2015-2019 14.0.24212

Et voilà, SEB Configuration tool now it's working as expected. Just a little addition to symptoms: with the "bugged" DLLs, each time we load a new configuration, SEB cftool says "Current settings have unsaved changes..." but I didn't make any change, then load the same settings file and the BEK has changed.
With the older DLLs both the symptoms, the "save warning" and the "BEK keep changing" disappear.

Probably there are some non-retro compatible changes in the DLLs, maybe in some "default" for some functions...

[dbuechel]

That would be very strange indeed. I have never seen such a malfunction nor has it been reported this way up to now, but will keep an eye open for it. However, I have the suspicion that it is something else which might be affected, but not caused by the redistributable. Either way, I most unfortunately cannot reproduce the issue and thus cannot really contribute much to the problem.

[rabser]

This sounds strange to me also, but we tested reinstalling the new one and the error appears again. Removing the new one and recovering the older (always removing the DLLs by hand as they are locked by some other processes using them) SEB returns ok.
The DLLs from VC++ depend only on windows DLLs that are not changeable (very core os), so I couldn't figure out any other cause.

[rabser]

Finally, we understood that this bad behaviour happens in newer releases when we add some support software (eg. a specific jdk for our purposes) into the seb program folder. We were used to adding some tools needed for doing exams and the first choice was to create some subfolders into the SEB program folder and put them there.
Now this breaks something into the BEK calculus, which will vary each time we open the SEB config tools. Removing all "external" files from the SEB program folder it's enough to run fine.
I kindly suggest either verifying what's happening (some type of overflow?) or adding a warning in the windows documentation, not changing/adding files in any way to the seb program folder content.

HTH

[dbuechel]

Yes exactly, that is the entire idea of the BEK: To verify the application as well as the configuration used to perform an exam.

[rabser]

The only problem I see it's that this is not clearly stated in the documentation, or I missed reading some pages?

[dbuechel]

You're correct, the information regarding the BEK functionality is distributed over several pages:

https://safeexambrowser.org/windows/win_usermanual_en.html#ExamPane
https://safeexambrowser.org/developer/seb-integration.html
https://safeexambrowser.org/developer/documents/SEB-Specification-BrowserExamKey.pdf

[rabser]

But adding files into the SEB program directory along with the other ones does not alter the integrity of SEB...
The SEB integrity should be calculated from the SEB files only, or this behaviour should be clearly stated.

[dbuechel]

But adding files into the SEB program directory along with the other ones does not alter the integrity of SEB...

It potentially could, hence SEB (as well as the SEB Verificator) checks the entire installation directory for alterations of any nature.

[rabser]

If I'm the administrator of a system (it's not a matter of OS, windows, linux, bsd or anything else) I should be able to add subdirectories anywhere in my system, and this is not necessarily breaking anything.
Anyway, I think that a key that's it's keeping changing it's not the right way of communicating that SEB thinks that it's installation was tampered...
Obviously, take your choice, our are suggestions.

[danschlet]

IMHO Windows Installer doesn't like at all when you do any manual changes in directories of applications installed by it. In the best case uninstall just doesn't remove stuff you changed manually or added, but we also had bad issues with damaged Registry which had to be cleaned up manually.

On macOS most of the .app bundle directory cannot be changed in any way (also not adding files), otherwise the app's code signature will be invalidated. If Microsoft would ever realize that ALL executables and resources should be protected by code signatures, then this would also apply to Windows (but probably they prefer to continue making their system vulnerable for manipulations...).

Whatever, if you like to mess around with software then enjoy. Just don't complain if a software which must be protected against manipulations won't appreciate that.

[rabser]

Dear @danschlet , probably I was not clear. I'm not complaining anything about SEB. Only I believe that be more clear in documenting and communicating warnings/errors to users could help.

[danschlet]

Ok, I understand. The thing is that we will never be able to explain every little detail in our documentation so it would cover every issue or use case which are not expected by us. There is also a specific important reason why SEB doesn't show an error message while starting when it detects it was manipulated. I cannot explain this here, but it is security related.

[rabser]

In the seb itself I can understand, bu what if the warnings appear in the seb config tools /BEK page ?
... or writing something in the logfile ?

[danschlet]

There is an entry in the log file.

[rabser]

In three people reading the log we missed that entry...

[rabser]

sigh.