Mobile middleware platform for secure vessel traffic system in IoT service environment

Transcription

1 SECURITY AND COMMUNICATION NETWORKS Security Comm. Networks 2016; 9: Published online 10 November 2014 in Wiley Online Library (wileyonlinelibrary.com) SPECIAL ISSUE PAPER Mobile middleware platform for secure vessel traffic system in IoT service environment Namje Park 1 * and Hyo-Chan Bang 2 1 Department of Computer Education, Teachers College, Jeju National University, Jeju-si, Korea 2 Electronics and Telecommunications Research Institute (ETRI), Daejeon, Korea ABSTRACT The Inter-VTS Data Exchange Format (IVEF) service is the draft standard designed for exchange of information on sea traffic between the vessel traffic systems and between the vessels. Standardization of this service is under way as a part of the next-generation navigation system, called e-navigation. The International Association of Lighthouse Authorities suggests, on its recommendation V-145, the IVEF service model and the protocol for provisioning of this service. But the detailed configuration of this service must be designed by the users. IVEF service is aimed at establishing a common framework to ensure exchange of ship information between vessel traffic service (VTS) centers gained via automatic ship identification device, closed-circuit television, radar system and other devices. Robust exchange of marine traffic information between VTS centers through IVEF service will enable related authorities to identify location of domestic and international ships in the coastal waters real-time and predict expected sea route, thus ensure effective sea route control and pre-emptive response to potential disasters or accidents. This paper suggests, based on the basic service model and protocol provided in the recommendation V-145, the implementation of the Jeju-VTS middleware, which will facilitate exchange of information on sea traffic. This paper developed a system enabling IVEF service simulation under an Internet of Things environment made possible by improving IVEF software development kit, which is an open source. For this, a mobile phone loaded with Android platform and desk top PC has been used for emulation of a ship on voyage and VTS center. Copyright 2014 John Wiley & Sons, Ltd. KEYWORDS android platform; e-navigation; IVEF; VTS; IoT; internet of thing; mobile middleware; vessel traffic system *Correspondence Namje Park, Department of Computer Education, Teachers College, Jeju National University, 61 Iljudong-ro, Jeju-si, Jeju Special Self- Governing Province, , Korea. namjepark@jejunu.ac.kr 1. INTRODUCTION A vessel traffic service (VTS) is a marine traffic monitoring system established by harbor or port authorities, similar to air traffic control for aircraft. Typical VTS systems use radar, closed-circuit television (CCTV), VHF radiotelephony and automatic identification system to keep track of vessel movements and provide navigational safety in a limited geographical area. As electronic technology has been developing, a number of ship- and shore-based electronic devices have been used for vessels such as Automatic Identification System (AIS), Electronic Chart Display and Information System, and Long Range Identification and Tracking systems. In addition, internet technology is being adopted for safe, economic and efficient movement of vessels and maritime disasters. Therefore, electronic gadgets on a vessel and protocols between vessel traffic systems need to be standardized. e-navigation is a concept developed under the auspices of the UN s International Maritime Organization to bring about increased safety and security in commercial shipping through better organization of data on ships and on shore, and better data exchange and communication between the two. An effort to set a new global standard for e-navigation, which is a new concept of ship navigation system, is underway with the aim to secure stable ship navigation, preserve marine environment and provide security-related services in marine activities. International Maritime Organization under UN is providing sponsorship for this initiative. The objective of e-navigation, which is the next-generation ship navigation system based on electronic technology and IT, is to collect, integrate, exchange and analyze marine information between ships and between sea and land. The International Association of Lighthouse 500 Copyright 2014 John Wiley & Sons, Ltd.

2 N. Park and H.-C. Bang Mobile middleware platform for secure vessel traffic system Authorities (IALA) has developed Inter-VTS Data Exchange Format (IVEF) as the standard for mutual VTS data communication in e-navigation system and standardization is currently underway. The IVEF service is the draft standard designed for exchange of information on sea traffic between the vessel traffic systems and between the vessels. Standardization of this service is under way as a part of the next-generation navigation system, called e-navigation [6,7]. The IALA suggests, on its recommendation V-145, the IVEF service model and the protocol for provisioning of this service [1,5]. But the detailed configuration of this service must be designed by the users. IVEF service is aimed at establishing a common framework to ensure exchange of ship information between VTS centers gained via automatic ship identification device, CCTV, radar system and other devices. For this, a number of models such as data model, interaction model and security model are being proposed, and XML-type basic protocol to deliver them has been distributed. Robust exchange of marine traffic information between VTS centers through IVEF service will enable related authorities to identify location of domestic and international ships in the coastal waters real-time and predict expected sea route, thus ensure effective sea route control and pre-emptive response to potential disasters or accidents. Furthermore, an international collaboration system between countries that use standard protocol assists effective response to threats from pirates. This paper suggests, based on the basic service model and protocol provided in the recommendation V-145, the design of the Jeju-VTS (J-VTS) mobile middleware, which will facilitate exchange of information on sea traffic. The J-VTS middleware consists of various components for providing the IVEF service and for processing the IVEF message protocols. The vessel traffic systems and the vessels corresponding to upper-layer applications may use the IVEF service with the functions provided by the J-VTS middleware, and the services are designed to be accessed according to the security level of users. And this paper developed a system enabling IVEF service simulation under a wireless environment made possible by improving IVEF software development kit (SDK), which is an open source [1,3]. For this, a mobile phone loaded with Android platform and desk top PC has been used for emulation of a ship on voyage and VTS center [24,26]. 2. RELATED WORK 2.1. Introduction of VTS system Generally, the factors that comprise of VTS system are shown in Figure 1, where the VTS center on land, various sensors (CCTV, Radar, DF, MET and sensors) and the base station with AIS with the control center with actual VTS utilization are connected in a communication net of ship, satellite and sensors in the control system. The FP project in Europe promoted various e-navigation studies, including next-generation vessel transportation control related technologies of VTS, VTMIS and PCS. This is the e-navigation project that will be realized in to provide cruise support and search and rescue service through safe and efficient information management by collecting the various pieces of information, such as vessel movements and docking, sea area climates, geography and environment, with diverse equipments. In addition, the MarNIS project carried out by the European Union studied the wide sea area communication technology for Figure 1. System architecture of vessel traffic service. Security Comm. Networks 2016; 9: John Wiley & Sons, Ltd. 501

3 Mobile middleware platform for secure vessel traffic system N. Park and H.-C. Bang an improved multimedia vessel communication. Especially, the improved sea area control function and vessel multimedia communication function were studied, and the practical service realization and international standards request continuous future research IVEF protocol The VTS Committee of IALA is a framework of methods and services to promote the safety, security, efficiency and environment protection in all transportable waters that is evolving from a traditional VTS to an e-navigation service. In other words, this service structure is advanced from the vessel traffic monitor and control to business service and e-navigation in vessel computing environment as a new service form. The various information collection and management in the sea encountered a rapid development in its technology, which aims to provide the information service for the vessels during their voyage, such as sea situations and sea map vessel support. At this time, the vessel information collection /management/production/ sharing/provision services should be enabled through the information collection from vessels or trusted information exchange between the land systems [1,6,28]. The IVEF service is a gateway service in the currently developing land system structure by IALA-AISM s e-navigation working group. In other words, the IVEF service can have an external third party system linking structure as the client that requests the service, and the mutually trusted network gateway security service is required. Figure 2 shows the IVEF information exchange of VTS center with other users and institutions, such as neighboring control center, control institutions within the control area or other relevant institutions. As shown in the figure, the traffic information provides the necessary information to the nearby system through the IVEF service. IVEF service should be defined as a mutually linked service between domains. In addition, for a safe IVEF service, the land systems of regional VTS, national VTS, related institutions and companies should be interconnected in a safe structure. The IVEF service is a server/client model serving as a protocol to exchange traffic information between VTS systems. Its development based on open source is underway by IALA and its protocol and sample program can be checked by downloading SDK in OpenIVEF website [2]. Basic actions to provide service between server/client take three steps as follows. In the first step, a client requests server certification and receives login reply if he or she is a legitimate user. In the second step, the server provides a certain service for the specific user only if it has such service. If it does not offer such service, it provides a basic service defined in the standard called Basic IVEF Services. In this step, the client can designate area of interest, data renewal period or data form based on his or her preference. In the third step, the client sends logout message to the server in order to end use of IVEF service. Because the server does not give a separate reply on the logout message, all the client has to do is just cancel access to server when he or she sends the message [4,6]. The IALA, which is the basic protocol to provide IVEF service between VTS centers, defines nine messages as shown in Table I. Definition of these messages is composed of XML-type schema, and all messages are composed of sub-elements of MSG_IVEF, which is the most significant element. Message of each sub-element also has its own sub-elements based on message characteristics. IVEF messages are broadly divided into control information message and real-time information message. The former consists of user certification and termination, service request to the server and its reply message and others to provide information on server status. The latter controls ship s current location, expected route, destination port and other physical information in an object data. The main purpose of object data is to exchange the following information: Figure 2. Vessel traffic service (VTS) and Inter-VTS Data Exchange Format (IVEF) service. 502 Security Comm. Networks 2016; 9: John Wiley & Sons, Ltd.

4 N. Park and H.-C. Bang Mobile middleware platform for secure vessel traffic system Table I. Inter-VTS Data Exchange Format interface message define. Message From To Control information message Login Client Server Login response Server Client Logout Client Server Ping Both Both Pong Both Both Service request Client Server Service request response Server Client Service status Server Client Real-time information message Object data Server User real-time tracking positions, static vessel information and voyage related information. 3. PROPOSED J-VTS SERVICE ARCHITECTURE 3.1. Linking service structure among VTS domains The linking service among domains (gateway service) is regionally or globally connected as shown in Figure 3 [6]. The structure in Figure 3 can include the VTS domain headquarters that oversees all of the VTS s within the domain, such as harbor VTS (harbor arrival and departure control), shore VTS (shore area control), National VTS (overseas vessel control) and domain headquarters VTS (national or large scale policy management and gateway). The VTS domain headquarters can manage the policies and authorities with other domains and is organized in a hierarchical manner by the VTS domain headquarters to separate the roles of the control even with the centers under different departments through transfer of right to control. Figure 3. Structure of the vessel traffic service (VTS) domain service. Security Comm. Networks 2016; 9: John Wiley & Sons, Ltd. 503

5 Mobile middleware platform for secure vessel traffic system N. Park and H.-C. Bang 3.2. Domain security factor definition and management flow map This clause defines the mutual security factors between domains and detailed procedures using the defined security messages. In other words, Figure 4 shows the security management flow map on the linking areas with the security messages where the VTS domain B approaches VTS domain A[7 9]. The basic security structure uses the XML-based standard protocols, and the characteristics for IVEF are expanded using the IVEF security message characteristic exchange protocol. The approach management procedures according to the procedures and authorities for the policy management within a domain when the domains are linked are shown in Figure 4. After the IVEF service between the domains is requested, the VTS IVEF service basic certification mechanism based on ID/Password with the access limitation based authority function is as follows. (1) The user sends the access request to use the system resources or application service. At this time, the access request is the same as the existing methods with user ID and password. (2) The Policy enforcement Point (PEP) of the access control receives the access request and confirms the user s ID and password with the access control list. This is the same as the previous method. (3) Once the VTS PEP (VPEP) confirms the user ID and password, it will transmit the user ID and the requested items (read, write, execute) to VTS Policy Decision Point (VPDP). (4) VPDP loads the policy from Policy Administration Point and determines whether the user has the appropriate authorities for the requested actions. For this, the user, resource, environmental characteristics and policy are used to determine whether to approve. (5) VPDP delivers the result to VPEP. In other words, approval/denial is delivered to VPEP. When it is approved, the user certificate is examined and if it is valid, then the user request is approved. (6) VPEP downloads the user certificate from the storage and checks for validity. If it is valid, it approves the access. The VTS basic authority management certificate mechanism procedures with access limitation do not have a huge advantage because the VTS system becomes more complex and the costs for the access control increases compared to the existing system, but it makes the integration of the access control system easier. Because it uses the standard technology of XACML and X.509 PMI, if the newly added system requires access control, the access determination does not have to be realized again. In other words, the additional open access control function in VTS basic authority management certificate access control system only needs to add the communication between the user and VPEP, and the rest can be on the existing realizations. Even if it is an independent system, the access control function can be reused, and it can reduce the costs for access control when adding the service system. Figure 5 shows the conditional user access control mechanism for VTS mutual linkage [10 12]. The conditional user access control mechanism for VTS mutual linkage is used when VTS domain B approaches the overall VTS service system provided by Figure 4. Inter-VTS Data Exchange Format (IVEF) security process. 504 Security Comm. Networks 2016; 9: John Wiley & Sons, Ltd.

6 N. Park and H.-C. Bang Mobile middleware platform for secure vessel traffic system Figure 5. User access control mechanism for vessel traffic service (VTS) mutual linkage. the external system through the internal system and works as follows. The VTS domain B user opens an account based on the overall VTS service system certification and authority mechanism and also opens an account at the VTS service system. Before the overall VTS service system can approve the approach of the VTS domain B user, the VTS service system inquires the overall service related characteristics. In addition, the VTS service system can have its own VPEP and VPDP. In this case, VPDP returns the authority decisions attached to the conditional tasks on the VTS service characteristics. Therefore, VPEP transmits the authority decision request to the external service. VTS service receives the authority decision request from VPEP and returns the characteristic token, and this is used to examine the conditional tasks from VPEP on the VTS service system. What follows is the conditional user access control mechanism procedures for VTS domain linkage related characteristics [13 15,35]. (1) VTS domain B requests the VTS service system access. (2) VTS service system transmits the authority decision request to service. This is performed by the VPEP within the VTS service system or the external VPEP of VTS service system. (3) Once VTS service receives the authority decision request from the VPEP of VTS service system delivers the authority decision request to PEP. (4) VPEP transmits the XAML characteristic decision request to VPDP. (5) VPDP confirms the VTS domain B account, characteristics and policy to transmit the approval/denial decision to VPDP. (6) If the authority is approved, VPDP will transmit the SAML characteristic token to PEP. (7) VPEP transmits SAML token. (8) VTS service transmits the token to VTS service system. (9) VTS service system provides the VTS domain A service to VTS domain B. 4. PROPOSED J-VTS MIDDLEWARE PLATFORM 4.1. Security enhancement of user authentication scheme The IVEF is an open-source SDK for VTS information exchange that is being developed by IALA and is almost complete in its international standardization as a gateway. The official IVEF technology documents provided by IALA specify that the data security except for authentication and authorization is out of the IVEF scope. The IVEF security suggested at this point only codes the user authorization information in an open key method. However, when the physical link is terminated and then reconnected between VTS s, the VTS system may be delayed from temporary traffic overload. This may lead to data leakage. A solution requires studies on the main authorization server. This section suggests the main authorization server for user authentication as shown in Figure 6 [27,29]. Figure 7 briefly summarizes the information exchange system after authentication for the Main Authentication Server (MAS) with the IVEF Client (IC) and IVEF Server (IS). The MAS is composed of Authentication Server (AS) and Ticket Granting Server (TGS). Figure 7 shows the protocol between IC, IS and MAS. Step 1 in Figure 7 shows how IC requires to confirm the user from the AS in MAS using the login information. Step 2 is the issuing of the session key after the certification of the IC in AS. Step 3 is the request of the TGS ticket issuing from TGS with the issued Session key. TGS ticket holds Security Comm. Networks 2016; 9: John Wiley & Sons, Ltd. 505

7 Mobile middleware platform for secure vessel traffic system N. Park and H.-C. Bang Figure 6. Main authorization scheme for user authentication in Inter-VTS Data Exchange Format (IVEF). Figure 7. Secure protocol between IVEF Client, IVEF Server and Main Authentication Server (MAS). the Client ID, IP address, Ticket issue time and ticket validity information. Step 4 sends the IC confirmation certified in AS in MAS to IS. Step 5 requests the Login information from IC by IS directly. Step 6 is the request of the server authentication with the Client Login information. Step 7 is the result delivery after the comparison of the confirmation from AS in step 4 and the client login result. Step 8 confirms the issued session key in step 2. Lastly, step 9 certifies IC and IS by issuing the same TGS ticket if there were no errors in all steps [6,17,18,25]. Therefore, MAS can authenticate IC and IS at the same time to sense the link termination in certain areas. In addition, the TGS ticket IP address and ticket valid time information can prevent the illegal access and replay attack of the attackers [30 32,36] Proposed VTS mobile middleware platform This paper suggests the J-VTS (Jeju National University- Vessel Traffic System) middleware structure to implement the IVEF service model. J-VTS consists of components and functions, which abstract the IVEF protocol and the IVEF service, enabling the vessel traffic system and vessels to easily use the IVEF service. The J-VTS middleware is designed in consideration of all models recommended in the IALA recommendation V-145: the data model, the security model, the interface model, the interaction model, the test model and the admin model. The J-VTS middleware has additional components; one analyzes and creates the IVEF messages in consideration of the IVEF message protocol, and the other provides specific actions in accordance with the result of the analysis. Figure 8 illustrates the overall architecture of the J-VTS middleware. J-VTS is divided into three layers. The first layer is the application layer, which corresponds to the vessel traffic system or vessels in service. The second layer is the J-VTS standard function layer. It consists of functions, which, on the application layer, communicate with major components of the J-VTS middleware and control the related components. The third layer consists of 12 components, which provide the IVEF service, send/receive messages under the IVEF protocol base and collect/analyze various sensor data [33,34]. For emulation of mutual data transmission/reception via IVEF between VTS server and ship, this paper used smart phone loaded with Android Gingerbread version as the VTS client system. For VTS server emulation, Intel Core-i5 desk top PC installed with Windows 7 was used. Communication between these systems is provided via wireless Internet network, and IVEF SK has been revised to fit the system to ensure convenient maintenance and protocol s scalability. 506 Security Comm. Networks 2016; 9: John Wiley & Sons, Ltd.

8 N. Park and H.-C. Bang Mobile middleware platform for secure vessel traffic system Figure 8. Jeju-vessel traffic service (J-VTS) mobile middleware architecture VTS mobile client program The J-VTS Client program is based on Android version (Gingerbread), and nine major message protocols have been implemented upon recommendation from IALA s V-145. The messages organized interface using Android s list view, and the very message is requested to the server once a certain item in the list view is selected. Message request is in XML format as per V-145 recommendation, and the server makes an equivalent message reply after analyzing the requested message. The received message is displayed as major information acquired by parsing XML message transmitted from server securedtype of data as shown in the right of Figure 9. A client program is written with Android-based Java. As for network, it is written based on the Java TCP/IP protocol stack, and the UI components provided by the Android platform for user interface. The main codes for implementation of the client are as follows [7,8,19,20,25]: (1) developed on the Android Gingerbread platform, (2) MainActivity showing the protocol list, (3) the thread requesting messages from the server through the socket communication and extracts useful information from the received xml file, (4) ViewerActivity showing the xml file and useful information on the display, (5) actual V-145 recommended library, (6) the XmlMsgCreator code creating the xml file based on the recommended library and (7) the handler processing the library-parsed codes. Figure 9. Inter-VTS Data Exchange Format (IVEF s) client menu. Security Comm. Networks 2016; 9: John Wiley & Sons, Ltd. 507

9 Mobile middleware platform for secure vessel traffic system N. Park and H.-C. Bang 4.4. VTS server system The major function of a server program is to receive V-145 recommendation message requested from the client via a specific port, analyze the requested message and provide proper navigation information. As per V-145 recommendation, Basic IVEF Services service has to be implemented, and other services can be provided as an addition. First, the server creates a separate thread whenever a client accesses into the server to process client s message. The requested message then distinguishes the message among IVEF interface messages in Figure 10 in the protocol analyzer implemented as Simple API for XML parser. The service provider then organizes services required by Figure 10. Server s flow chart. the user following user certification procedure and creates XML message as per V-145 recommendation for transmission to the client. All at the same time, information related to server s user interface is renewed to allow the user to monitor communication status between the server and the client. Screen of the server program is split into four parts, that is, Server Connection menu to start server operation, Server Status Monitoring, Request Protocol, Useful Information and Sending XML Message as shown in Figure 11. Server Status Monitoring shows IP, port, stand-by status of server in service, client s access time and other client s access information. Request Protocol shows messages requested by clients and analysis of the requested messages via protocol analyzer described in Section 3.2. Useful Information shows XML information analyzed via protocol analyzer, and data information is managed in container structure based on message classification. Sending XML Message shows texts of transmitted messages converted in XML-type format as per V- 145 recommendation. The final converted XML data are sent to the client via TCP/IP stack (Figure 12). The server program is written with the Java language. The daemon runs with the TCP/IP protocol stack provided by Java, and the user interface is implemented with Java Swing. If the server program is started initially and a user starts the server, a thread is created, waiting for access of a client. This thread uses the protocol developed in this project as the library, and performs the functions in accordance with this protocol. The main components for implementation of server and the implementation details are as follows [21 23,37,38]: Figure 11. Inter-VTS Data Exchange Format (IVEF s) server operation. 508 Security Comm. Networks 2016; 9: John Wiley & Sons, Ltd.

10 N. Park and H.-C. Bang Mobile middleware platform for secure vessel traffic system Figure 12. Inter-VTS Data Exchange Format (IVEF s) service message transaction. (1) using the Java-based TCP/IP protocol stack, (2) using the Java Swing-based UI framework, (3) using the v-145 recommended protocol library developed in the project, (4) the thread creating and transmitting messages requested by the clients through the socket communication, (5) the handler code processing the final XML-parsed result and (6) the message creator code encoding messages into the recommended XML files. Figure 13 showed a difference for 4 s that compares average transfer time between client and mobile J-VTS middleware of middleware filtering and unfiltering by network. This showed a phenomenon that increases until 4 s according to an increased tag number on the whole protocol time. Figure 13. Simulation result of Jeju-vessel traffic service middleware filtering. Security Comm. Networks 2016; 9: John Wiley & Sons, Ltd. 509

11 Mobile middleware platform for secure vessel traffic system N. Park and H.-C. Bang Figure 14. Simulation result of mobile middleware non-filtering. Figure 14 showed an average transmission time according to increased tag number in non-filtering protocol environment. If tag number increases, we can see that the average transfer time increases on the whole protocol time. And average transfer time increases rapidly in case the tag number is more than 45. Therefore, the tag number that can process stably in computer on testbed environment grasped about 40 (at the same time). Compared with the difference of filtering time and protocol time, the time of mobile middleware platform s filtering module is occupied and shows that the importance of signature module about 32% of whole protocol time. implementation work have not been carried out. Therefore, further study is required to finish the detailed design of the J-VTS middleware suggested in this study, to verify applicability and to examine the improvement. By doing so, we were able to emulate mutual data exchange status between ship and VTS centers and to predict applicability of IVEF service in the real world. At present, security procedures or policy on IVEF service do not have a defined standard, which requires further study, and IVEF protocol should be improved and a new protocol design needed to ensure that radar information and video information on CCTVs can be provided in an efficient manner. 5. CONCLUSION These days, the latest electronic technologies and IT are being employed for safer ship operation and efficient control of marine traffic. e-navigation relies on IVEF service as the standard to exchange data between VTS centers. IVEF, however, is still a program under development, and thus, its actual implementation and performance have not been fully verified. This paper suggests J-VTS as the middleware that provides the IVEF service. And this paper implemented IVEF client on the mobile phone loaded with Android platform and IVEF service server on desk top PC. J-VTS is the middleware that provides the IVEF service between the vessel traffic systems and between vessels. It is designed to provide, using various functions provided by J-VTS, functions, such as IVEF service provisioning, data security, protocol test, incorporation of data and incorporation of sea traffic image. The overall structure design of the middleware is finished, but a detailed design of each component and the actual ACKNOWLEDGEMENTS This paper is extended and improved from accepted paper of CSA 2012 conferences. This work was supported by the Electronics and Telecommunications Research Institute (ETRI) grant funded by the Korean government (14ZC1310, Development of USN/WoT Convergence Platform for Internet of Reality Service Provision) and Basic Science Research Program through the National Research Foundation of Korea (NRF) funded by the Ministry of Education (2013R1A1A4A ). REFERENCES 1. IALA Recommendation V-145 on the Inter-VTS Exchange Format (IVEF) Service, E-Navigation from Wikipedia, the free encyclopedia OpenIVEF Project Homepage, 4. A security architecture of the inter-vts system for shore side collaboration of e-navigation Security Comm. Networks 2016; 9: John Wiley & Sons, Ltd.

12 N. Park and H.-C. Bang Mobile middleware platform for secure vessel traffic system 5. International Association of Lighthouses and Aids-to- Navigation Authorities (IALA), Interface Control Document for IVEF, Release Lee B, Cho H, Han J, Park N. A Security Architecture of the inter-vts System for shore side collaboration of e-navigation. Journal of navigation and port research, 2012; 36(1): Park N, Cho S, Byung-Doo K, Byunggil L, Won D. Security enhancement of user authentication scheme using IVEF in vessel traffic service system. Lecture Notes in Electrical Engineering 2012; 203: Kyunghwan K, Byung-Doo K, Byunggil L, Park N. Design and implementation of IVEF protocol using wireless communication on android mobile platform. CCIS 2012; 339: Kang T, Park N. Design of J-VTS middleware based on IVEF protocol. LNCS Arifin B, Ross E, Brodsky Y. Data security in a ship detection and Identification system. IEEE RAST ; Carter B, Green S, Leeman R, Chaulk N. SmartBay: better information better decisions. IEEE OCEANS 2008; Frejlichowski D, Lisaj A. Analysis of lossless radar images compression for navigation in marine traffic and remote transmission. IEEE Radar Conference 2008; Garnier B, Andritsos F. A port waterside security systemic analysis. IEEE WSS Conference ; Park N, Kwak J, Kim S, Won D, Kim H. WIPI mobile platform with secure service for mobile RFID network environment. In APWeb Workshops LNCS, Vol.3842,Shen HT, Li J, Li M, Ni J, Wang W (eds). Springer: Heidelberg, 2006; Park N. Security scheme for managing a large quantity of individual information in RFID environment. In ICICA CCIS, Vol.106,Zhu R, Zhang Y, Liu B, Liu C (eds). Springer: Heidelberg, 2010; Park N. Secure UHF/HF dual-band RFID: strategic framework approaches and application solutions. In ICCCI LNCS. Springer: Heidelberg, Park N. Implementation of terminal middleware platform for mobile RFID computing. International Journal of Ad Hoc and Ubiquitous Computing 2011; 8(4): Park N, Kim Y. Harmful adult multimedia contents filtering method in mobile RFID service environment. In ICCCI LNCS (LNAI), Vol.6422,Pan JS, Chen SM, Nguyen NT (eds). Springer: Heidelberg, 2010; Park N, Song Y. AONT encryption based application data management in mobile RFID environment. In ICCCI LNCS (LNAI), Vol.6422,Pan JS, Chen SM, Nguyen NT (eds). Springer: Heidelberg, 2010; Park N. Customized healthcare infrastructure using privacy weight level based on smart device. Communications in Computer and Information Science, Vol. 206, Springer: Heidelberg, 2011; Park N. Secure data access control scheme using typebased re-encryption in cloud environment. Studies in Computational Intelligence, Vol. 381, Springer: Heidelbergm, 2011; Park N, Song Y. Secure RFID application data management using all-or-nothing transform encryption. In WASA LNCS, Vol.6221, Pandurangan G, Anil Kumar VS, Ming G, Liu Y, Li Y (eds). Springer: Heidelberg, 2010; Park N. The implementation of open embedded S/W platform for secure mobile RFID reader. The Journal of Korea Information and Communications Society 2010; 35(5): Kim Y, Park N. Development and Application of STEAM Teaching Model Based on the Rube Goldberg s Invention. Lecture Notes in Electrical Engineering, Vol. 203, Springer: Heidelberg, 2012; Park N, Cho S, Kim B, Lee B, Won D. Security Enhancement of User Authentication Scheme Using IVEF in Vessel Traffic Service System. Lecture Notes in Electrical Engineering, Vol. 203, Springer: Heidelberg, 2012; Ko Y, An J, Park N. Development of Computer, Math, Art Convergence Education Lesson Plans Based on Smart Grid Technology. Communications in Computer and Information Science, Vol. 339, Springer: Heidelberg, 2012; Kim Y, Park N. The Effect of STEAM Education on Elementary School Student s Creativity Improvement. Communications in Computer and Information Science, Vol. 339, Springer: Heidelberg, 2012; Kim Y, Park N. Development and Application of STEAM Teaching Model Based on the Rube Goldberg s Invention. In Vol. 203,Yeo S, Pan Y, Lee YS, et al (eds). Springer: Netherlands, 2012; Kim Y, Park N. The Effect of STEAM Education on Elementary School Student s Creativity Improvement. In Vol. 339, Kim T, Stoica A, Fang W, et al (eds). Springer: Berlin/Heidelberg, 2012; Kim Y, Park N. Elementary Education of Creativity Improvement Using Rube Goldberg s Invention. In Vol. 180,Park JH, Kim J, Zou D, et al (eds). Springer: Netherlands, 2012; Kim G, Park N. Program Development of Science and Culture Education Tapping into Jeju s Special Security Comm. Networks 2016; 9: John Wiley & Sons, Ltd. 511

13 Mobile middleware platform for secure vessel traffic system N. Park and H.-C. Bang Characteristics for Adults. In Vol. 339,Kim T, Stoica A, Fang W, et al (eds). Springer: Berlin/Heidelberg, 2012; Taysi ZC, Yavuz AG. ETSI compliant GeoNetworking protocol layer implementation for IVC simulations. Human-centric Computing and Information Sciences 2013; 3(4): Do-keun K, Ki HC, Choi K. A dynamic Zigbee protocol for reducing power consumption. Journal of Information Processing Systems 2013; 9(1): Adwitiya S, Lobiyal DK. Performance evaluation of data aggregation for cluster-based wireless sensor network. Human-centric Computing and Information Sciences 2013; 3(13): Liu J, Chung SH. An efficient load balancing scheme for multi-gateways in wireless mesh networks. Journal of Information Processing Systems 2013; 9(3): Choi HY, Min SG, Han YH, Koodli R. Design and simulation of a flow mobility scheme based on proxy mobile IPv6. Journal of Information Processing Systems 2012; 8(4): Lee B, Park N. Performance Improvement Based Authentication Protocol for Intervessel Traffic Service Data Exchange Format Protocol Based on U-Navigation System in WoT Environment. Journal of Applied Mathematics, Vol. 2014, Article ID Hindawi Publishing Corporation, 2014; Park N. Design and Implementation of Mobile VTS Middleware for Efficient IVEF Service. The Journal of Korea Information and Communications Society 2014; 39C(6): Security Comm. Networks 2016; 9: John Wiley & Sons, Ltd.