Sprint Retrospective 6

2 May 2018 @ 11:45pm by erik

During Sprint Retrospective 6 I continued to learn more about the CryptoJS library, encryption, Angular, and Git. From the CryptoJS npm page, this code snippet helped me understand how data is encrypted and decrypted using the CryptoJS library:

var CryptoJS = require("crypto-js");
var data = [{id: 1}, {id: 2}]
// Encrypt
var ciphertext = CryptoJS.AES.encrypt(JSON.stringify(data), 'secret key 123');
// Decrypt
var bytes  = CryptoJS.AES.decrypt(ciphertext.toString(), 'secret key 123');
var decryptedData = JSON.parse(bytes.toString(CryptoJS.enc.Utf8));

This function takes a set of data, and a given private key, encrypts the data, and returns and the encrypted string.

Decrypt a Record

public decryptRecord(ciphertext: string, privateKey: string) : string{
    let bytes  = CryptoJS.AES.decrypt(ciphertext.toString(), privateKey);
    let decryptedData = JSON.parse(bytes.toString(CryptoJS.enc.Utf8));
    return decryptedData;

This function takes the encrypted string, and a private key and returns the decrypted string.

I learned a lot of information about Typescript and web applications, I learned more about Node.js, encryption, and Javascript. I feel this information will help me in my professional career, especially if I am working with web development and API’s. I am interesting in further contributing to this open source project, and possibly more. I would like to improve my skills in Javascript and Angular. I would like to learn more about Angular testing and continue to work on the tests I wrote for my functions, to make sure they are working properly.

The team was successful in finding a suitable cryptography library that had all the features we were looking for, but we did run into trouble getting CryptoJS implemented in the ampath application. I successfully implemented the features for encrypting and decrypting a data record, hopefully it will be used to help future teams encrypt patient data. I think I spent too much time researching and not enough time actually working with the ampath application. I did find though that the solution I needed was easier that I thought it would be. We all hit some roadblocks getting things to always work, sometimes the ampath application would give us compilation errors out of nowhere.

During this Sprint we continued working on our respective parts of the encryption service. I successfully wrote two functions, one to encrypt a data record and one to decrypt a data record. I wrote test files for the functions that I believe will work but had some trouble getting the tests to work. Once we made the decision to use CryptoJS, I used this source to help me contribute my part to the project. I pushed my part of the project to my local repository and then made a pull request for the group repository. I did have some trouble with Git dealing with merge conflicts and setting the remote, but feel I was due for a refresher and eventually solved my problems.

1 comment

Sprint Retrospective 5

18 April 2018 @ 02:44pm by erik

This sprint I learned a lot more about encryption services and typescript in general. Encryption using Javascript is not the best choice, especially in an open source project but I feel the solution we have will do the job and securely encrypt the data in the more secure way we can. I learned there are many solutions to our problem and a lot of solutions may be outdated or not maintained. We chose Crypto-JS to hash passwords and encrypt and decrypt data, it’s a popular Javascript crypto library and has an MIT license. The last update was a year ago but still feel this properly accomplishes what we want. I noticed there are a lot solutions for Javascript but not many are implemented in Typescript. I learned quite a bit about translating from Javascript to typescript and was able to implement a solution for an encryption function in a typescript service file. I learned more about testing in Angular 2 but still am having some trouble with tests. I will keep on focusing on writing good tests that comply with the Ampath standards. I enjoy getting to work on something that’s actually used by people, and will help people do their job. It’s nice to get experience working with a real web application that uses Javascript and APIs. I feel this will help me in my professional career, and will help the Ampath team improve their project.

I felt the team worked well during the sprint. We have all been having problems keeping the web application working and it seems to break even though the local files have not been touched. We all have the application working now and are on to writing the functions needed for the other teams to utilize. We have split up the tasks amongst ourselves and will hopefully have a working solution by the end of the the next sprint. I don’t see anything stopping up from completing the tasks, and we got the O.K. from Jonathan on the Ampath team on the encryption API interface. I am currently working on the encryptRecord function and am utilizing Crypto-JS for that. I have a function now that I think will do the job but still need to work on my angular 2 testing skills to make sure the function will work properly.

We began the sprint with the intention of creating an encryption service file that has the following functions: hashPassword, a function that hashes passwords with a salt when the user logs in. clearLocalSalt, a function that will clear the local salt generated at login, when the user logs out. encryptRecord, a function that takes data and a private key and encrypts the data for save local storage. decryptRecord, a function that takes the private key and encrypted data and decrypts it for when the user is connected to the internet. Now that we have a clear path and the O.K. from the ampath team, we can concentrate on our individual tasks and work the offline login team for assistance in generating a salt with a username and timestamp.


Sprint Retrospective 4

5 April 2018 @ 04:19pm by erik

During Sprint 4, our team worked individually on different encryption libraries to gain a little more insight into the quality and usability of each one. I continued to research WebCrypto API and found the performance of the library to be much faster than other encryption libraries.

The test platform was a MacBook Pro (MacBookPro11,5) with a 2.8 GHz Intel Core i7 running MacOS 10.13 Beta (17A306f) and Safari Technology Preview 35.

On the WebKit blog, authors noted what they thought the disparity was caused by, “Working with our JavaScriptCore team, we learned that the causes of these pure JavaScript implementations not performing well is that most of them are not actively maintained. Few of them take full advantage of our fast JavaScriptCore engine or modern JavaScript coding practices. Otherwise, the gaps may not be that huge.”  WebCrypto API also boasts better security models and gives an example why: “When developing with pure JavaScript crypto libraries, secret or private keys are often stored in the global JavaScript execution context.” Noting this leaves users extremely vulnerable as “keys are exposed to any Javascript resource being loaded”, and allows XSS attackers to steal the keys. WebCrypto API protects the secret or private keys by storing them completely outside of the Javascript execution context. Implementations on MacOS and iOS are based on CommonCrypto routines “which are highly tuned for our hardware platforms, and are regularly audited and reviewed for security and correctness.” They go on to say WebCrypto API is the best way to ensure the highest security protection. WebCrypto sounds like a great resource for quality encryption services but there are others that perform the same tasks and can do what we want securely. The team has decided to focus on CryptoJS, which in this case I don’t think performance will be a big issue, but will keep this information close because I may need it in the future.

I feel the team worked well during this sprint and learned a good amount amount each library. Respectively we worked on bcryptjs, webcrypto api, pouch-db/crypto-pouch, and forge. All options seemed to get the job done but felt that CryptoJS suited our needs the best, while still keeping in mind the Ampath team might have a different preferred encryption library. We all learned more about encryption, Javascript, and the use of Typescript services. My personal interest in security and encryption has increased after working on this project, and all the news we see every day about the privacy of consumers data being compromised.

The first week of the sprint, I spent researching WebCrypto API, looking for a solution to implement that into ng2-amrs. I found documentation but not many examples of how to implement it in Angular 2. I found examples written in Javascript but had trouble getting things to work. I found it difficult to  translate Javascript into Typescript, and how that is going to used in a Typescript service. While meeting with the team we decided that while the encryption libraries we all tested has their own pros and cons, we decided that CryptoJS best suits what we need to get an encryption service running. CryptoJS has more a little more information on how to implement what we need to get our encryption service running.




Sprint Retrospective 3

17 March 2018 @ 09:24pm by erik

During sprint 3, I worked more with encryption services and Webstorm trying to create a working an Angular app that encrypts and decrypts data using Webcrypto API. I have been researching the Webcrypto API for some time as it is completely new to me, including Javascript. I learned that there are not many Angular related examples of the Webcrypto API but I did find an example using Crypto JS that I am also interested in and I believe it will help me understand cryptography and how its implemented in Angular.  This resource had a lot of good information including why Webcrypto API is a good choice.

  • WebCrypto offers protection against overwriting (in Chrome), since window.crypto.subtle is read-only. This is good news for security but bad news for usability, because it makes it harder to work with polyfills.
  • Non-extractable keys make it very hard for attackers to steal your keys. Therefore, the “JavaScript is always insecure” issue is mostly resolved. You can create a key, store it at the client, and use it. But if you don’t specify it, you can never read the key, which means that attackers cannot do so. Tip: Use IndexedDB to store the keys.
  • WebCrypto uses SSL only (with the exception of localhost and extensions) which ensures that the data sent between the web server and the browser is encrypted and secure.

I think the team worked well on the day we were together in class. We missed class because of the weather and that was unfortunate because I feel more accomplished when I get to work with my team face to face. I am working hard learning about encryption, how it works, and what the current standard for secure web encryption is so we have a good path to start after getting the o.k. from the AMPATH team on a direction to go. I believe we are all learning something new about web cryptography, as we are all focusing on different javascript libraries. I plan to bring what I learn from the Webcrypto API to the team and allow us to make an informed decision on what encryption library we should choose.

During spring 3, I spend most of my time researching Web Cryptography API, including webcrypto-examples on GitHub. I’ve been using what I learn from the documentation and examples to get a working implementation on an app of my own to help the team move forward in creation of an offline module. I started focusing on the Webcrypto API because it seemed like a good starting point as it’s a popular javascript library that outperforms others significantly. The algorithm I am focusing on is AES-GCM, “the symmetric block cipher ratified as a standard by National Institute of Standards and Technology of the United States (NIST)” During the latest sprint meeting the team, we decided to keep working on our respective projects implementing an encryption service, once we meet after spring break we will began to make a game plan as to what to pitch to the AMPATH team.


Sprint Retrospective 2

28 February 2018 @ 11:15pm by erik

During Sprint Retrospective 2, I learned more about the OpenMRS REST endpoints that Ampath uses for it’s core services. I learned more about what the Ampath team is looking for in terms of an encryption service if we are using open source code. In general they are looking for stability: i.e. number of contributors, number of commits, recent activity, any big name (Google, Microsoft, etc), and adaptability. I learned there is a standard Webcrypto that most browsers use as a standard and that we should stick to that standard. I learned more about time planning, and the need to do a better job documenting what we are doing, and splitting up tasks for individuals to work on.

The team worked well, I’m more productive when we are all together going through the code on the projector. It’s nice to have others looking at the same material you are, sometimes they notice things you don’t and it helps everyone on the team learn. I try to participate and offer any tips or advice I might have. I try being prepared for the sprint by trying to understand what is going on and how the services on the application work. I think we need to do a better job documenting everything we do and making sure to share it with those who it might help, with the addition of the documentation thread on slack, it will make sharing that information easier. Next sprint I am going to keep a log of what I am doing, or ideas I have as a personal log to help me organize and write my sprint retrospectives. Now that we have more of an idea what our team should be focusing on, we can start getting into the details of implementing the encryption service and how that ties in with the other functions being added by other teams.

During Sprint Retrospective 2, our team organized our trello board and began to add tasks we thought we could complete during the sprint. We planned on walking through some of the ng2-amrs services, looking into the REST endpoints (with the postman app), checking out Balsamiq, and to coming up with design ideas for implementing an offline service for ng2-amrs. We started our work by walking through some of the services in the openmrs-api folder. We went through some of the endpoint in the OpenMRS Rest Web Services API wiki. We looked into the service that sets a users location, the patient search function, the offline / online indicator, and we began to see how those services work with the front end, and the OpenMRS api that performs a lot of the functions on ng2-amrs. We began to turn our attention to finding out how to implement a service that encrypts and decrypts data. We did some research online for possible solutions and found a few options that we shared with the Ampath team asking for their input: bcryptjs, forge, crypto-js. We are going to look more into forge because it seems to have the most activity.