개요

구분

팀프로젝트 (2020 제7회 소프트웨어개발보안경진대회)

개발인원

3명 (졸음 감지센서 개발 1, 수집 서버 및 API서버(백앤드) 개발 1, 프론트 개발 1)

프로젝트 개발 기간

20.8(2일)

소스

• https://github.com/nbiosupr/dyfawd-server
• https://github.com/nbiosupr/pos-dummy-data

성과

2020 제7회 소프트웨어개발보안경진대회 행정안전부장관상(우수상)

시연 영상 링크 및 설명

• https://youtu.be/5onWKiN6sK4

• 첫번째로 IOT 센서 시연입니다. 졸음 감지와 방지 경보 발생, 데이터 전송 기능을 보여드리겠습니다. 먼저 HTTPS 통신을 통해 디바이스를 인증하여 토큰을 발급받습니다. 그리고 가속도 센서와 머신러닝으로 졸음을 감지하여 데이터를 전송합니다.

• 두번째로 API 서버 시연입니다. 신뢰성있는 데이터를 유지하기 위해 센서에 인증 토큰을 발급합니다. 데이터 수집입니다. JWT 토큰의 유효성을 확인하고 DB에 기록합니다. 좌표를 주소 문자열로 변환하기 위해 네이버 지오코딩 API를 사용했습니다. 이 과정들은 HTTPS로 암호화 됩니다. 웹사이트를 통해 DB에 반영된 모습을 보고 계십니다.

• 세번째로 시각화 웹사이트와 OPEN API 시연입니다. 여기는 대시보드입니다. 졸음 운전 누적순위 졸음 운전 레벨, 졸음운전 전국 현황 지도를 볼 수 있습니다. 여기는 상세페이지 입니다. 연도, 월별, 시간대별, 지역별로 데이터를 조회하여 시각화합니다. 그래프와 표로 시각화하고 있습니다. OPEN API 문서화 페이지 입니다. 이를 통해 요청 데이터와 응답데이터 형식을 확인하고 테스트할수 있습니다.

서비스 요약

• 안전에 관련된 서비스를 기획하는 동시에 보안성도 충족하도록 설계하였음.
• 제7회 소프트웨어 개발보안 경진대회에 출전하여 행정안전부 장관상을 받음.

기능

• 졸음운전을 감지하여 사용자를 깨우고 데이터를 수집
• 졸음운전 데이터를 실시간으로 수집하여 통계자료로 가공하고 제공하는 서비스
• 지역별 졸음 빈도, 시간별 졸음 빈도, 졸음 발생 시간과 위치 데이터 제공
• 실시간 졸음 빈도를 졸음 레벨로 계산하여 시각화
• OPEN API 형태로 데이터를 제공하고 API문서를 제공.

사용 기술

• 졸음감지 센서의 하드웨어는 NVDIA Jatson Nano(하드웨어) + GPS센서 + 카메라모듈 + 가속도센서.
• 졸음감지 센서의 로직은 파이썬으로 pynmea2, GPIO, urlib, ssl, smbus, OpenCV 사용.
• 졸음감지 센서와 수집 서버의 통신은 센서의 인증 문제를 해결하기 위해 JWT 토큰을 사용.
• 종단간 암호화를 위해 HTTPS 적용.
• 수집 및 통계 API서버는 AWS EC2 컨테이너에 스프링 부트를 기반으로 개발된 자바 어플리케이션.
• JWT 토큰과 HTTPS 통신 등을 위해 Spring Security 모듈을 적극활용하였고 Spring Data JPA(ORM)을 사용하여 DB를 제어.
• Swagger를 사용하여 REST API에 대한 문서를 제공
• 프론트는 지도 시각화를 위해 Kakao Map API를 사용.

기여

역활

• 팀장
  • 서비스 기획과 시스템 설계를 주도하였음.
  • 서비스에 대한 PT를 담당하였음.
• 더미 데이터 수집 및 가공
  • 공공데이터포털에 있는 교통 데이터를 가공하는 스크립트를 작성
  • 이를 통해 300여건의 데이터를 얻음.
• 수집 서버 및 API서버(백앤드) 개발자
  • 데이터베이스 설계 및 ORM 라이브러리를 사용하여 구현
  • 수집 서버 및 API서버 설계 및 구현
  • 수집 서버와 센서간 통신 인증 구현
  • Swagger를 활용한 API 문서 제작
• 프론트 개발 지원
  • REST API 요청 후 응답 JSON 데이터 사용 가이드라인 제공
  • 응답 JSON 데이터를 Kakao MAP API에 적용

내가 사용한 기술

• 개발환경
  • Windows 10 1909 x64
  • IntelliJ Professional 2020.2
  • Amazon Linux1(AWS EC2)
• 기술
  • JDK8
  • Spring Boot 2
  • MariaDB
  • H2
  • Spring data JPA
  • Gradle
  • Git, Github
  • JUnit
  • Retrofit
  • Naver Reverse Geocoding API

개발 과정

1) 수집, 통계 데이터 가공, 웹서버

• REST API 서버와 웹서버는 JAVA8 환경의 SpringBoot2를 기반으로 개발. WAS는 톰캣.
• Spring Security 모듈을 적용하여 JWT 토큰을 사용하였음. 토큰은 센서와 수집서버간의 통신 중 인증문제를 해결하기 위해 사용함. 네트워크 상 토큰 이동 중 노출을 막기위해 SSL 통신을 적용하였음.

2) 데이터 수집 데이터베이스

• DB에는 테스트와 제출을 위해 2가지를 사용할 것인데 H2와 MariaDB를 사용.
• H2는 메모리 DB이므로 개발 중 빠른 테스트를 위해 사용하고, MariaDB는 AWS 환경에서 서버를 돌릴 때 사용.
• 기본적인 라이브쿼리 취약점을 피하기 위해 Spring Data JPA 모듈을 사용하였음. SQL 매핑으로 직접 DB를 다루지 않고 ORM을 통해 DB를 다뤘음. DB 설계또한 Relation 기반이 아닌 ORM에 맞는 도메인 주도 개발을 적용하려 노력하였음.

3) 개발환경과 배포 환경

• 개발 중에는 Windows 10 1909 x64 환경에서 IntelliJ Professional 2020.2를 사용하였음.
• 빌드도구로는 Gradle을 사용했음.
• GitHub를 통해 AWS EC2 인스턴스에 배포하였음.

4) 좌표로 주소 문자열 변환

• GPS 좌표를 주소로 변환하기 위해 Naver Reverse Geocoding API를 사용하였음.

Cryptonite(엔드포인트 데이터 보안 솔루션)

“Cryptonite”의 목표는 각 문서에 대한 기밀성 유지뿐만 아니라, 인증된 사용자가 보호 중인 문서를 필요할 때 언제든 사용할 수 있는 가용성 기능까지 갖춘 솔루션을 만들어 내는 것이었습니다. 각 문서들을 AES 암호화 기술을 통해 암호화하였고, 공격자가 불순한 의도로 보호 중인 문서를 손상시켰을 때, 다시금 복구할 수 있도록 서버에 백업하는 클라우드 기능을 갖추도록 계획하였습니다. 암호 알고리즘의 구현에 대한 정보가 많이 부족했지만, 도서관에서 관련 서적을 모조리 찾아 공부하여 개발하였습니다.

개요

구분

팀프로젝트 (2016년도 2학년 1학기 수원대 정보보호학과 OOP 수업 프로젝트)

개발인원

4명 (개발자 2, 디자이너 2)

프로젝트 개발 기간

16.5 ~ 16.6 (2달)

성과

해당 강의 프로젝트 성적 1위

프로젝트 사용 스택

• JAVA
• Cryptography(PBKDF2, AES256, SHA256)
• TCP 통신

기능

• 파일 자동 암호화
  • 사용자의 보호폴더의 변화 확인시 실시간 폴더감지 모듈에서 감지.
  • 암호화 알고리즘 AES-256을 사용하여 대상파일을 암호화.
  • 암호화 키는 PBKDF2로 해싱된 패스워드.
• 파일 자동 백업
  • 파일이 암호화되면 실시간 폴더감지 모듈에서 즉시 감지하고 서버로 백업.
• 파일 복원
• 유저간의 파일 전송수신
  • 1:1 파일 공유로써 보내고자하는 사람이 전송하고자 하는 파일을 선택하면 OTP가 발급.
  • 그 OTP를 파일을 받는 사람이 입력하면 파일을 받을 수 있음.
  • 한번 받은 파일은 서버에서 삭제되며 서버에서의 최대 보관기한은 48시간.
• 위치 추적 기능
  • whois api를 활용하여 ISP 단위 위치 확인. 도난을 방지.

견본

Github

https://github.com/nbiosupr/cryptonite

참여

역활

• 팀장
• 암호화 모듈 개발
• 복호화 모듈 개발
• 클라이언트단 통신 모듈 개발
• Swing을 활용한 UI 개발
• 복원 모듈 개발
• 복원 UI 개발
• 윈도우 콘텍스트 메뉴 추가

  문제 해결법

• 키관리 문제
  • 대칭키 암호화의 가장 큰 문제는 키관리.
  • PBKDF2를 활용해 사용자의 패스워드를 암호화 키로 사용할 수 있음을 알게됨
  • 이를 적용하여 암호화키를 서버에 백업하지 않게 됨.
• 서버와의 통신
  • 당시 프로토콜의 개념이 미비하였음.
  • 시리얼 통신과 같이 네트워크 통신을 하려다 보니, 각 패킷의 구분이 불명확.
  • 별도의 프로토콜이 필요함을 알게 됨.
  • 파일 전송을 위한 프로토콜을 개발.
• 복호화 프로그램 단일 프로세스화와 윈도우 콘텍스트
  • 파일을 오른쪽 클릭했을 때 바로 복호화 프로그램으로 연결하고 싶었음.
  • 윈도우 콘텍스트라는 키워드를 모르던 상태
  • 교수님께 자문을 구했고, 보안 솔루션을 개발하는 NSHC 소속의 개발자를 소개 시켜주심.
  • 학교는 화성이었지만, 열심히 의왕까지가서 그 것이 윈도우콘텍스트라 불림을 알게됨.
  • 또한 뮤텍스를 활용해, 단일 프로세스화가 가능함을 배움.

스마트 FOD CAR 통제시스템 콘솔(시연용)

공군에 제안한 작전 개선안을 시연하기 위해 만든 프로그램입니다. 관리 콘솔과 가상차량 프로그램으로 구성되어 있고, TCP를 기반으로 설계한 애플리케이션 계층 프로토콜을 통해 통신합니다. 실시간으로 이벤트와 트랩을 주고 받기 위해 P2P방식으로 통신되게 구현하였고, 콘솔과 차량을 위한 통신 프로토콜과, 차량 간의 통신을 위한 프로토콜이 별도로 존재합니다.

개요

구분

팀프로젝트 (2018 공군 창의 혁신 아이디어 공모 해커톤)

개발인원

1명 (시연 통제시스템 콘솔 개발 1) ( 그 외 시연 차량 엔지니어 1, 프로젝트 타이틀과 맞지 않아 제외)

프로젝트 개발 기간

18.7(2일)

성과

2018 창의 혁신 아이디어 공모 해커톤 최우수상 수상

프로젝트 사용 스택

Python

기능

• 관리 차량 프로그램 전체 상태 간략 확인
• 관리 차량 프로그램 상태 세부 확인
• 관리 차량 프로그램 제어
• 관리 차량 프로그램 위치 값 확인
• 관리 차량 프로그램 위치 값 제어
• 관리 콘솔과 관리 차량 프로그램 간 통신
• 관리 차량 프로그램 간 통신

견본

시연 영상 링크

• https://youtu.be/SPKaR-U-huI

사진

개발 배경

• “FOD”란 활주로 위에 있는 볼트와 같은 이물질로 인해 생기는 항공기 결함.
• "FOD 제거 작전"은 이를 줄이기 위해 주기적으로 부대 내 모든 장병이 활주로로 나가 대열을 이뤄 활주로 바닥의 이물질을 수거하는 작업
• 공군 비행단에선 정기적으로 “FOD제거 작전”을 실시
• 이 작업은 시간 소모, 인력 소모가 매우 큼
• 이를 개선하고자 공군 TDD-LTE 망을 활용해 상호 통신하고 딥러닝 기술로 만들어진 모델로 이물질을 판단하며 플래투닝 자율 주행을 하는 스마트 FOD 차량 솔루션을 기획.
• 이를 위한 시연품 개발이 필요

개발 과정

• 군 복무 중이었으므로 장비 활용이 자유롭지 못함. 특히 통신 기능을 갖춘 모듈은 사용할 수 없었음.
• 기존에는 아두이노와 그외 키트를 활용하여 시연 차량 3대를 만들고, 관리 콘솔을 만들어 통신할 계획이었으나 무산.
• 차량의 통신기능을 빼고 별도로 제작하고, 콘솔을 위해 가상차량 프로그램을 만들어 시연하기로 계획.
• 가상 차량 프로그램은 기존 차량과 같은 상태를 가진 통신 프로그램.
• 콘솔을 이 가상 프로그램과 통신 시켜 시연.

github

https://github.com/nbiosupr/Auto-Multiple-Picture-Uploder

루팡 (스마트폰 루프스테이션 어플리케이션)

구분

팀프로젝트 (2019 한이음)

개발인원

4명 (개발자 4, 그중 2명 UI 디자인 겸업)

프로젝트 개발 기간

19.7 ~ 19.11(5개월)

성과

2019 한이음공모전 한국정보산업연합회장 상

깃헙 주소

https://github.com/injae/Loopang

프로젝트 사용 스택

• Kotlin(안드로이드, 클라이언트)
• RxAndroid(클라이언트,UI)
• Kotlin coroutine library(클라이언트, UI, 비지니스로직)
• Figma (클라이언트, UI, 프로토타입제작)
• Retrofit(클라이언트, 통신)
• okHttp API(클라이언트, 통신)
• Docker(서버)
• Python(서버)
• Flask(서버)
• JWT(서버, 세션관리),
• PostgreSQL, SQLAlchemy(DB, ORM)
• GitHub, GitLab(버전관리)

기능

• 모바일 디바이스 만으로 루프스테이션을 활용한 음악 창작 방식을 그대로 재현하여 즉흥적으로 반주를 창작할 수 있습니다.
• 기존 녹음된 소리 위에 새로운 소리를 녹음하여 반주를 만들 수 있습니다.
• 점점 쌓이며 녹음되는 음원소스들을 레이어라고 부르는데, 이펙터라는 특수한 효과 모듈을 사용하여 레이어의 톤을 조정할 수 있습니다.
• 창작된 반주를 바탕으로, 반주를 조작하거나 보컬을 추가하여 하나의 곡을 만들 수 있습니다.
• 녹음 시 화이트노이즈를 제거하여 음질을 개선할 수 있습니다.
• 녹음 시 메트로놈 기능을 지원합니다.
• 제스처 기반 UI, UX를 제공합니다.
• 자신의 음원소스를 타인과 공유할 수 있습니다.
• Feed에서 최신소스, Like top 5 리스트를 볼 수 있습니다

  견본 이미지

  

  시연 영상 링크

• https://www.youtube.com/watch?v=Tu0eyBPZUZg

  참여

  역활

• 클라이언트개발
  • 루프스테이션 로직 개발 및 리팩토링 (
  • 최종믹싱 UI와 비즈니스 로직 연결 부분 개발 (이펙터 연결, 볼륨조절, 바이트 길이 시간 변환 등)
• UI개발
  • 로그인 및 회원가입
  • 루프스테이션 UI ( 제스처 구현, 녹음, 메트로놈, Realtime Sound Visualizer, Sound Visualizer 등)
  • 프로젝트 매니저 UI ( 메인 View, 사운드 프리뷰, 그 외 다이얼로그 등)
  • 최종 믹서 UI ( 메인 View, 애니메이션을 이용한 뷰 크기 지속 변환 등)
    • 그 외 유틸리티 ( 증폭 값 배열 변환 로직, 프로젝트 중복체크 로직 등)
• UI 디자인
  • 스플래시, 로그인 및 회원가입 UI
  • 루프 스테이션 메인 UI
  • 프로젝트 매니저 UI
  • 최종 믹싱 UI

내가 사용한 기술

• Kotlin(안드로이드, 클라이언트)
• Kotlin coroutine library(클라이언트, UI, 비지니스로직)
• Figma (클라이언트, UI, 프로토타입제작)
• PCM Data에 관한 기본 지식(SampleRate, BitRate 등)

문제 해결 과정

1. 프로젝트 관리 측면

• 초기, 각 구성원의 코드를 하나로 취합하기 어려움을 느낌
• Github를 사용하여 협업하는 방법을 익혀 해결
• 각자 맡은 파트의 진행상황을 상시 파악할 수 있게 되었고, 빠르게 코드 리뷰를 할 수 있게 되었음.

2. UI 프로토타입

• 프로젝트 초기에 UI의 프로토타입을 종이나 칠판에 그려서 개발하였음.
• 깔끔하게 그리는데 시간이 오래 걸렸고, 미술능력을 부모님께 상속받지 못해 알아볼 수 가없었음.
• Figma 라는 프로토타입 솔루션을 알게되어, 기본적인 사용방법과 추출, 트리거 기능에 대해 공부함
• UI/UX 설계 사항을 더 자세히 전달할 수 있게 됨.

3. 녹음 상황 실시간 Visualizing

• Android에서 제공하는 Waveform은 기본 제공 녹음 라이브러리에 특화되어 있어 프로젝트에 적용하기 무리가 있음.
• 직접 만든 모듈에 적용하기 위해 OpenSource API를 확인하였지만, 모두 목적에 부합하지 않음
• Custom View 제작 필요성을 느낌.
• 적용한 해결방안1 : 팀원들의 코드를 모두 분석 및 음원소스가 어떤 형태로 저장되는지 파악
• 적용한 해결방안2 : 증폭값을 View에 맞게 계산해내는 알고리즘 작성 및 언제나 View에 녹음된 데이터 시각화
• 적용한 해결방안3 : Custom View에 대한 별도의 공부로 원하는 스타일의 파형을 그려 Realtime Visualizing 문제 해결

4. 작업파일 로딩 문제

• 각자 다른 영역에 있는 프로젝트뷰어와 프로젝트 창 간에 데이터 송수신 문제 발생

• 적용한 해결방안 : 송수신 작업을 추상화 하여 인터페이스를 두어 액티비티 전달

4. 리스트 뷰 어댑터의 뷰 재활용 문제

• 리스트뷰는 아이템의 개수에 맞춰 모든 뷰를 생산하지 않고 몇개의 아이템 뷰를 만들어 재활용하는 방식
• 적용한 해결방안 : 리스트뷰에 ViewHolder 패턴을 도입하여 문제 해결

5. 일정한 속도로 크기가 변화하는 뷰

• 별도의 스레드를 사용하여 레이아웃파라미터를 변경하는 것은 관리가 몹시 어려움.
• UI Thread 동작 방식으로 인해 변경에 대한 결과 반영이 즉시 되지 않는다는 문제점을 가짐.
• 변화 값을 단순 정수로 관리하기엔 값들이 소스 등지에 산재하게 되어 관리가 어려움
• 각 시간 단위마다 비례식을 계산하여 변환하기 위한 함수의 필요성이 느껴짐
• 적용된 해결 방안 1: 시간 대비 픽셀 크기를 나타내는 클래스를 별도 제작하고 메소드로 변환식을 구현.
• 적용된 해결방안 2: 애니메이션에 대해 공부하여, 무한 반복되는 애니메이션을 적용

6. 지속적으로 크기가 변환되는 뷰를 아이템으로 가지는 리스트뷰 문제

• 리스트뷰는 아이템의 개수에 맞춰 모든 뷰를 생산하지 않고 몇개의 아이템 뷰를 만들어 재활용하는 방식.
• 아이템이 되는 뷰의 크기가 계속하여 업데이트 되는 중 교체되므로 널 포인터 문제가 발생함.
• 갱신될 때 마다 뷰를 새로 만들게 되면 오버헤드가 증가
• 적용된 해결 방안 : 리스트뷰를 리니어뷰로 교체, 리스트뷰와 같은 기능을 갖도록 별도의 함수를 추가 제작하여 문제 해결.