Re: Klassifiserte dokumenter og sikkerhetsnivå i Nikita Noark5 Core

[Ole Aamot]

Hei igjen Thomas,

On Fri, Aug 12, 2022 at 3:57 PM Thomas Sødring via nikita-noark <
nikita-noark at nuug.no> wrote:

> Interessant Ole!
>

:-)


> Jeg mistenker at det materialet det er snakk om her er på papir. Om det er
> snakk om 15 esker med feks minnepinner så snakker vi type Snowden
> nedlasting. Kanskje han kommer til å forsvare seg meg at han fjernet
> graderingen av innholdet mens han var president og derfor var det helt
> lovlig å gjøre det! Du kan gjøre mye rart når du er konge!
>

*Aftenposten skriver på lederplass fredag 2. september 2022:*

*"USAs føderale politi (FBI) etterforsker tidligere president Donald Trump
for mulige lovbrudd.*

*Trump beholdt til dels høyt graderte dokumenter etter at han flyttet ut av
Det hvite hus.*

*FBI mistenker blant annet at Trump tidligere i år aktivt gjemte bort slike
statshemmeligheter.*

*Denne intensjonen om å holde noe unna, kan bli juridisk avgjørende.*

*Samtidig gav Trump og hans folk nemlig inntrykk av å samarbeide med USAs
nasjonalarkiv (Nara).  En mengde papirer ble overlevert med beskjed om at
Nara nå hadde fått "alt".*

*Under en politiaksjon i Trumps hjem i Florida i august fant FBI likevel en
rekke dokumenter med høy gradering.  Noen var så hemmelige at byråets
agenter og Justisdepartements advokater måtte gis økt sikkerhetsklarering
for å kunne lese dem."*

Kryptering av innhold i en dokumentasjonsforvaltningsystem er fortsatt noe
> jeg ikke støtter. Men, jeg må innrømme at jeg ikke er 100% sikker på det.
>

Hvordan er Nikita Noark5 Core med tanke på nivåer av gradering av innhold?


> Dersom dokumentasjon er kryptert så vil det ikke være mulig å søke i det
> (innhold, tittel osv), så det er en annen slags bruksperspektiv på
> materiale enn det jeg hadde brukt feks nikita til. Men det kan være lurt å
> samle kryptert og ukryptert fordi da har du alt i et system.
>

Sant.


> Med kryptert materiale er du sårbar med tanke på senere  lesbarhet dersom
> den private nøkkelen blir borte. Jeg har opplevd at arkivmateriale blir
> avlevert til depot uten at nøkkelen også avleveres. Jeg har hørt (men ikke
> fått det bekreftet) at folk krypterer dokumentasjon med sine private
> BankID. Det blir spennende å se om det lar seg avlevere??? Det er kjent at
> folk signerer med sin private BankID i jobbsammenheng, men dette med
> kryptering var nytt for meg. Jeg går ut ifra at det ikke stemmer!
> Materialet bør dekrypteres før det avleveres til depot. Ting som er så
> sensitivt (nasjonal sikkerhet) hadde jeg ikke hatt i et system som er
> tilgjengelig på internett. Jeg kan ikke garantere at noen ikke finner en
> sær hull i et eller annet bibliotek som gjør at innhold lekker. Ingen kan
> garantere det!
>

Hva med å ta i bruk Microsoft Authenticator og/eller Google Authenticator
til autentisering i Nikita?  Begge universitene mine (UiO og NTNU) krever
tilgangskontroll via Authenticator og QR-kode som scannes i en
mobiltelefonapplikasjon og som benyttes til å bekrefte innloggingene.  Jeg
tror ikke at OsloMet har implementert dette enda.

Det er kanskje en grunn til det, hvis en mister nøkkelen, så må en henvende
seg til Authenticator kundeservice ved NTNU for å få resatt Autheticator
innloggingen.

Fra
https://oril.co/blog/two-factor-authentication-with-java-and-google-authenticator/

*Ihor Sokolyk* Lead Software Engineer | Expertise : Java, FinTech, System
integrations Linkedin <https://www.linkedin.com/in/ihor-sokolyk-822248108/>

I am more than sure that each of you have at least one account with enabled
Two-Factor Authentication (2FA). But if you are still unfamiliar with 2FA
I’ll give you some general explanation.

It’s a second step in login sequence that asks you to enter 6-digits code
sent to you by email, text message or Google Authenticator app and this
code expires in 30 or 60 seconds. This second step of authentication makes
your account more secure, because even if someone knows your login and
password, they still need your physical mobile device to see 2FA code sent
to you. Such approach is highly used in almost every single application,
especially if this application has deal with money, cryptocurrencies,
banks, transactions etc.

So in this article, as you may noticed, we will talk about using Google
Authenticator app with your Java-based application. Let’s get started!
Maven Project

First of all, let’s create a maven project and add the following
dependencies:

<dependency>
    <groupId>de.taimos</groupId>
    <artifactId>totp</artifactId>
    <version>1.0</version>
</dependency>

<dependency>
    <groupId>commons-codec</groupId>
    <artifactId>commons-codec</artifactId>
    <version>1.10</version>
</dependency>

<dependency>
    <groupId>com.google.zxing</groupId>
    <artifactId>javase</artifactId>
    <version>3.2.1</version>
</dependency>

Here is why we need those dependencies in our project:

   - *totp* – The Time-based One-Time Password algorithm (TOTP) is an
   extension of the HMAC-based One-time Password algorithm (HOTP) generating a
   one-time password by instead taking uniqueness from the current time.
   - *commons-codec*– for converting inputs to hex and base32.
   - *zxing* – library for generating QR codes.

Also you need to install Google Authenticator app to your smartphone. It’s
totally free and is available on App Store and Play Market. In order to add
new entry to Google Authenticator app you need to enter manually a secret
key or scan a QR code. I will show you how to use both of them in this
tutorial. Let’s start with manual one first.

Google Authenticator requires 20 bytes secret key encoded as base32 string.
We need to generate this key using the following code:

public static String generateSecretKey() {
    SecureRandom random = new SecureRandom();
    byte[] bytes = new byte[20];
    random.nextBytes(bytes);
    Base32 base32 = new Base32();
    return base32.encodeToString(bytes);
}

After running this method you should see the generated string with 32
characters. Please write down this string somewhere since this is our
secret key and we will use it later.

QDWSM3OYBPGTEVSPB5FKVDM3CSNCWHVK

Now open your Google Authenticator app. Press ‘*plus*’ button to add a new
entry and select ‘*Manual entry’.* In the ‘*Account’ *field enter your
email address or any name and in ‘*Key*’ field paste our secret key. Press
save button. You should see your entry in the list with 6-digits code that
is changing every 30 seconds.
[image: google aunteficator image]

Now let’s write a method that converts base32 encoded secret keys to hex
and uses the TOTP to turn them into 6-digits codes based on the current
time.

public static String getTOTPCode(String secretKey) {
    Base32 base32 = new Base32();
    byte[] bytes = base32.decode(secretKey);
    String hexKey = Hex.*encodeHexString*(bytes);
    return TOTP.*getOTP*(hexKey);
}

Now let’s run the following code to generate time-based 6-digits code in
sync with Google Authenticator.

String secretKey = "QDWSM3OYBPGTEVSPB5FKVDM3CSNCWHVK";
String lastCode = null;
while (true) {
    String code = *getTOTPCode*(secretKey);
    if (!code.equals(lastCode)) {
        System.*out*.println(code);
    }
    lastCode = code;
    try {
        Thread.*sleep*(1000);
    } catch (InterruptedException e) {};
}

If you did everything correctly then you should see the 6-digits code being
displayed in console every 30 seconds and this code should be synchronized
with code displayed in Google Authenticator. If they are not synchronized
then make sure that time on your PC and mobile device is in synch.
QR code

We have finished with manual entry example, so let’s jump to QR code which
is more user friendly and is used in most cases.

First of all we need to receive bar code data from google. It requires some
special format, so here is our method to generate this data.

public static String getGoogleAuthenticatorBarCode(String secretKey,
String account, String issuer) {
    try {
        return "otpauth://totp/"
                + URLEncoder.*encode*(issuer + ":" + account,
"UTF-8").replace("+", "%20")
                + "?secret=" + URLEncoder.*encode*(secretKey,
"UTF-8").replace("+", "%20")
                + "&issuer=" + URLEncoder.*encode*(issuer,
"UTF-8").replace("+", "%20");
    } catch (UnsupportedEncodingException e) {
        throw new IllegalStateException(e);
    }
}

Here is some notes about the generated string above:

   - Account is the user id in system. Usually it’s user’s email or
   username. It’s used to label entries within Google Authenticator.
   - Issuer is a company or organization name and is also used for
   labelling purposes.
   - All dynamic values must be URL encoded.
   - Google Authenticator doesn’t seem to deal with spaces encoded as plus
   signs. Encoding spaces as %20 seems to work.

Now run the above code with some test account name, issuer name and secret
key generated previously:

String secretKey = "QDWSM3OYBPGTEVSPB5FKVDM3CSNCWHVK";
String email = "test at gmail.com";
String companyName = "My Awesome Company";
String barCodeUrl = Utils.*getGoogleAuthenticatorBarCode*(secretKey,
email, companyName);
System.*out*.println(barCodeUrl);

You should receive a string in the following format:

otpauth://totp/Awesome%20Company%3Atest%40gmail.com?secret=7t4gabg72liipmq7n43lt3cw66fel4iz&issuer=Awesome%20Company

Now the last step is left – to generate a QR code. Let’s use ZXing library
to do it.

public static void createQRCode(String barCodeData, String filePath,
int height, int width)
        throws WriterException, IOException {
    BitMatrix matrix = new MultiFormatWriter().encode(barCodeData,
BarcodeFormat.*QR_CODE*,
            width, height);
    try (FileOutputStream out = new FileOutputStream(filePath)) {
        MatrixToImageWriter.*writeToStream*(matrix, "png", out);
    }
}

Calling this method with the string returned by the method in the previous
step as the 1st argument will write a PNG image to the specified path with
the specified height and width.
[image: qr-code image]

Go ahead and try to use your generated image with the “Scan barcode” option
you saw previously in Google Authenticator. After scanning this QR code you
should see a new entry in Google Authenticator entry list.

We can simulate user’ login into the system. Let’s imagine that user
entered his credentials and now he need to enter 2FA code from Google
Authenticator. Here is the easiest code snippet:

Scanner scanner = new Scanner(System.*in*);
String code = scanner.nextLine();
if (code.equals(*getTOTPCode*(secretKey))) {
    System.*out*.println("Logged in successfully");
} else {
    System.*out*.println("Invalid 2FA Code");
}

Of course this is just a pseudo code, but it simulates the real 2FA flow
and shows you if you did everything correctly.
Conclusion

Now you know the basics of two-factor authentication and you can try to
integrate it into your web-based application with a small efforts to add
more security to your application.

Hope you like this article. Do not forget to press ‘Clap’ button and share
this article with your friends. The full example can be found on my GitHub
<https://github.com/IhorSokolyk/google-2fa> account.

Have a great day! And don’t forget to enable 2FA in all your accounts:)

> Det som er viktig er at nikita har en god implementasjon av
> tilgangskontroll slik at folk ikke kan hente ut dokumentasjon de ikke har
> tilgang til. Det er noe jeg synes er verdt en diskusjon. OAuth claims opp
> mot roller i et arkivsystem.
>

Jeg tror at enten Microsoft Authenticator eller Google Authenticator er
veien å gå til gradering.

Se eksempler på Authenticator i Java på
https://oril.co/blog/two-factor-authentication-with-java-and-google-authenticator/

Mvh,
Ole


>  - Thomas
> ------------------------------
> *Fra:* nikita-noark <nikita-noark-bounces at nuug.no> på vegne av Ole Aamot <
> ole at aamotsoftware.no>
> *Sendt:* fredag 12. august 2022 15:39
> *Til:* nikita-noark at nuug.no <nikita-noark at nuug.no>
> *Emne:* Klassifiserte dokumenter og sikkerhetsnivå i Nikita Noark5 Core
>
> I hvilken grad kan USA og amerikanske myndigheter benytte Nikita Noark
> Core til å lagre sensitive opplysninger som ikke skal være offentlig
> informasjon og ser Dere på USAs myndigheter som en konsument av
> arkivsoftware med kryptering utviklet i Norge?
>
> I USA er det nå en kamp med FBI om utlevering av klassifiserte
> dokumenter om atomvåpen,
> etter at Trump har tatt med seg klassifisert informasjon fra Det Hvite
> Hus til sin
> ranch i Florida, som ble ransaket onsdag 10. august 2022 etter subpoena
> fra FBI.
>
>
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.nytimes.com%2F2022%2F08%2F11%2Fus%2Fpolitics%2Ftrump-fbi-subpoena.html&data=05%7C01%7Ctsodring%40oslomet.no%7C7f2fbd4fa078401dfe3608da7c681100%7Cfec81f12628645508911f446fcdafa1f%7C0%7C0%7C637959083799121808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qI9l3jm0tIgcKh%2BF4CWjb4ZDnK8w9CurrvRAtPFqFiU%3D&reserved=0
>
> Regner med at informasjonen i Nikita er kryptert med en
> krypteringsalgoritme og
> seed ved hjelp av passord.  Hvilken krypteringsmetode
> (RSA/DSA/ElGamal/Commfides)
> benytter Nikita til å kryptere informasjon eller er det ikke sikkerhet i
> systemet?
>
> Forventer egentlig ikke noe svar på dette, men regner med at Dere vet
> hva som kreves fra RSA Security LLC og Commfides for offentlige
> tjenester på høyeste sikkerhetsnivå (nivå 4).
>
> Mvh,
> Ole Aamot
> _______________________________________________
> nikita-noark mailing list
> nikita-noark at nuug.no
>
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nuug.no%2Fmailman%2Flistinfo%2Fnikita-noark&data=05%7C01%7Ctsodring%40oslomet.no%7C7f2fbd4fa078401dfe3608da7c681100%7Cfec81f12628645508911f446fcdafa1f%7C0%7C0%7C637959083799121808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ajnyA2UWNBVOwxy4FTY2MTuEMpHiceQBAPZ5rilSFH0%3D&reserved=0
> _______________________________________________
> nikita-noark mailing list
> nikita-noark at nuug.no
> https://lists.nuug.no/mailman/listinfo/nikita-noark
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.nuug.no/pipermail/nikita-noark/attachments/20220903/a521a34e/attachment-0001.htm>